From nobody Sun Jul 1 10:47:36 2018 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 2A548130E71; Sun, 1 Jul 2018 10:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG4tJh6ydfzO; Sun, 1 Jul 2018 10:47:25 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4220130E6D; Sun, 1 Jul 2018 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w61HlJED022461; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41JdBH3zGCzDXdR; Sun, 1 Jul 2018 19:47:19 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 552160036.771-3560f32e67c21b99b06b4537d19f474c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 1 Jul 2018 19:47:18 +0200 Message-Id: <19B520A9-2C13-44CA-AA76-AE8325320CBA@tzi.org> To: ace , Core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF102: FINAL AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:47:29 -0000 I forgot to send the update of my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The only change from the previous draft agenda (apart from different room assignments) seems to be the move of SECDISPATCH on top of the first CORE slot and of SUIT into what previously was the SECDISPATCH slot. The conflicts ACE vs. DISPATCH as well as CBOR vs. 6LO vs. TEEP remain. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Laurier INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Duluth ART *** core Constrained RESTful Environments WG Laurier INT intarea Internet Area Working Group WG Viger SEC secdispatch Security Dispatch WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Van Horne ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Duluth INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC *** suit Software Updates for Internet of Things = WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Duluth INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Laurier OPS v6ops IPv6 Operations WG Centre Ville RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Laurier IRTF*** t2trg Thing-to-Thing Viger OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Laurier SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Centre Ville IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Mon Jul 2 11:29:33 2018 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 A8369130DFA for ; Mon, 2 Jul 2018 11:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LugX59U7E-xf for ; Mon, 2 Jul 2018 11:29:23 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (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 D4EEC127148 for ; Mon, 2 Jul 2018 11:29:23 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id a3ZifIkfRb3AAa3ZjftLUx; Mon, 02 Jul 2018 11:29:23 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_AE1FE8EE-8F1B-471F-80F7-DDDF5657EEA6" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> Date: Mon, 2 Jul 2018 11:29:22 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfJPRv13Cz25QHOwc53BFaEV7zMn+VaVx2Ie0Sl4iXPbpffWsUErZR7amrTLo4ysT8Y2FOftgpDW6gumAtTLnMCcjSDCixjKMlpmUFq0pRo3k6cb2rQx9 GknETb8gNTsvHTG7YPGXd4chgbSf9BVWsfO8T+bUcQUgNWEgcyXKF5Tj Archived-At: Subject: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 18:29:29 -0000 --Apple-Mail=_AE1FE8EE-8F1B-471F-80F7-DDDF5657EEA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think that the more we can reduce implementation / encoding options = and variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about. Here is a PR for new text = for epoch time (tag 1). =20 I don=E2=80=99t know what the philosophy is for compatibility with RFC = 7049. This proposal breaks it. Maybe it should be a different tag value = or such because of that. The big break is disallowing floating point values because you can do = better in a number of ways by defining a new tag for time expressed in = micro or nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here = ). The general decoder implementor and protocol designer is left with only = two choices: - Support 64-bit time values or not - Support negative time values or not The protocol designer should of course make a call on these choices so = there aren=E2=80=99t interop problems. There=E2=80=99s more detailed rationale in the PR comments. I=E2=80=99m curious what you think. :-) LL --Apple-Mail=_AE1FE8EE-8F1B-471F-80F7-DDDF5657EEA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think that the more we can reduce implementation / encoding options and = variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about.

Here is a = PR for new text for epoch time (tag 1).  

I don=E2=80=99t know = what the philosophy is for compatibility with RFC 7049. This proposal = breaks it. Maybe it should be a different tag value or such because of = that.

The big = break is disallowing floating point values because you can do better in = a number of ways by defining a new tag for time expressed in micro or = nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here).

The general decoder implementor and protocol designer is left = with only two choices:
   - Support = 64-bit time values or not
   - Support = negative time values or not

The protocol designer should of course make a call on these = choices so there aren=E2=80=99t interop problems.
There=E2=80=99s more detailed = rationale in the PR comments.

I=E2=80=99m curious what you think. = :-)

LL


= --Apple-Mail=_AE1FE8EE-8F1B-471F-80F7-DDDF5657EEA6-- From nobody Mon Jul 2 12:11:07 2018 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 8E2A3130F5C for ; Mon, 2 Jul 2018 12:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWzucCBVg1V7 for ; Mon, 2 Jul 2018 12:11:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D630412F295 for ; Mon, 2 Jul 2018 12:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w62JAxCP022717; Mon, 2 Jul 2018 21:10:59 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41KH0L6wgdzDXr9; Mon, 2 Jul 2018 21:10:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> Date: Mon, 2 Jul 2018 21:10:58 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 552251456.48286-ef442f17a941686d660ad4aad3597b10 Content-Transfer-Encoding: quoted-printable Message-Id: <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 19:11:06 -0000 Hi Laurence, the representation of time is indeed one of those eternal issues in = representation formats. Tag 1 is relatively well-defined as it is, and I don=E2=80=99t think we = want to change that. Instead, new tags have been defined for time (and there, of course, also = has been tag 0). Not all tags need to be defined in the CBOR base document. In particular, in this round we are aiming to collect the stable parts = of CBOR, as opposed to putting in more bells and whistles. We are *not* defining a new version of CBOR (there are no versions in = CBOR). New bells and whistles can be added by just registering tags. The set of registered tags can at any time be examined at: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml Looking for =E2=80=9Ctime=E2=80=9D, we see (apart from 0 and 1): 1001 map extended time [draft-bormann-cbor-time-tag-01] This tag has been registered a while ago and already has been = implemented in some environments that care about precise time (e.g., = Haskell with its picosecond-based time). On to the specific changes that you propose: =E2=80=94 getting rid of floating point time =E2=80=94 I would expect = that is in active use, but I haven=E2=80=99t done a survey. It = definitely is allowed by RFC 8392 (which uses Tag 1 in an indirect way). = Floating point time has the weird property that its resolution gets = lower the further away you get from the epoch. But otherwise, it is = fine. Currently, of the 53 bits of resolution of a binary64, 31 bits = are taken for the integer part, so 22 bits remain for the fractional = part. That will change to 32+21 in 2038 =E2=80=94 a date that most = people who work with Posix times are aware of, as the integer time_t no = longer will fit in a signed 32-bit int then. So I don=E2=80=99t see any = deadly interoperability problems that would stop us from continuing to = support floating point valuess in tag 1. Any specific application can = be more selective, if desired. =E2=80=94 being more explicit about negative values (int or float). = Good point. - requiring support for =E2=80=9Cpositive=E2=80=9D (I think you mean = unsigned) integer values. Just as an application can rule out floats in = its usage of Tag 1, it could do so for integers. A generic CBOR = implementation that doesn=E2=80=99t support integer values here could be = considered not so bright, though. (CBOR is more about interoperability = than about conformance, anyway.) =E2=80=94 comments about serialization (encoding). I don=E2=80=99t = think a Tag should define that level of requirement. If an application = wants to use minimal-size encoding, so be it, but that=E2=80=99s none of = the business of a Tag. So, in summary, I=E2=80=99d say let=E2=80=99s pick a good way to handle = negative numbers (being aware that there is no really good way). = Probably MJD-based interpretations. But let=E2=80=99s talk to = astronomers here=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On Jul 2, 2018, at 20:29, Laurence Lundblade = wrote: >=20 > I think that the more we can reduce implementation / encoding options = and variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about. >=20 > Here is a PR for new text for epoch time (tag 1). =20 >=20 > I don=E2=80=99t know what the philosophy is for compatibility with RFC = 7049. This proposal breaks it. Maybe it should be a different tag value = or such because of that. >=20 > The big break is disallowing floating point values because you can do = better in a number of ways by defining a new tag for time expressed in = micro or nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here). >=20 > The general decoder implementor and protocol designer is left with = only two choices: > - Support 64-bit time values or not > - Support negative time values or not >=20 > The protocol designer should of course make a call on these choices so = there aren=E2=80=99t interop problems. >=20 > There=E2=80=99s more detailed rationale in the PR comments. >=20 > I=E2=80=99m curious what you think. :-) >=20 > LL >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Jul 2 16:32:46 2018 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 4DB6A130DC6; Mon, 2 Jul 2018 16:32:43 -0700 (PDT) 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.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057436326.16456.4430544863685146410@ietfa.amsl.com> Date: Mon, 02 Jul 2018 16:32:43 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-cddl-03.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 23:32:44 -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 data definition language (CDDL): a notational convention to express CBOR data structures Authors : Henk Birkholz Christoph Vigano Carsten Bormann Filename : draft-ietf-cbor-cddl-03.txt Pages : 55 Date : 2018-07-02 Abstract: This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-cddl-03 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-cddl-03 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 Tue Jul 3 09:02:38 2018 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 085EE130FC1; Tue, 3 Jul 2018 09:00:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cbor@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361502.4893.330745494467226527.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:15 -0700 Archived-At: Subject: [Cbor] cbor - Requested session has been scheduled for IETF 102 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:23 -0000 Dear Barry Leiba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cbor Session 1 (2:00 requested) Tuesday, 17 July 2018, Afternoon Session I 1330-1530 Room Name: Van Horne size: 130 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/cbor.ics Request Information: --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: artarea dispatch secdispatch saag extra jmap uta dmarc dcrup iasa2 core ace t2trg Second Priority: suit lwig anima 6tisch Third Priority: acme roll detnet sacm lpwan dots People who must be present: Carsten Bormann Barry Leiba Alexey Melnikov Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with ART and IoT-related BoFs Please avoid Friday: one chair has to leave on Thursday night --------------------------------------------------------- From nobody Wed Jul 4 13:38:40 2018 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 60DB5127148; Wed, 4 Jul 2018 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7Fr9x2lQaGB; Wed, 4 Jul 2018 13:38:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B8F12F295; Wed, 4 Jul 2018 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w64KcOEo020926; Wed, 4 Jul 2018 22:38:24 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41LXrH2gv7zDWnV; Wed, 4 Jul 2018 22:38:23 +0200 (CEST) Content-Type: multipart/mixed; boundary="Apple-Mail=_5C896E86-7EED-48AA-90F2-A78D22C86E90" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 4 Jul 2018 22:38:21 +0200 Cc: suit , cbor@ietf.org X-Mao-Original-Outgoing-Id: 552429499.581403-d32a5fa4b61def7196ff26dd6f4c8a26 Message-Id: References: To: Brendan Moran , =?utf-8?Q?=C3=98yvind_R=C3=B8nningstad?= X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] [Suit] draft-moran-suit-manifest-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 20:38:33 -0000 --Apple-Mail=_5C896E86-7EED-48AA-90F2-A78D22C86E90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 4, 2018, at 10:26, R=C3=B8nningstad, =C3=98yvind = wrote: >=20 > =E2=80=A2 CDDL nitpicking: > =E2=80=A2 Some name inconsistencies: ProcessingStep vs = Processor, TargetInfo vs Target. > =E2=80=A2 There's probably a typo in the definition of = Directive. Should it be an array of maps? > =E2=80=A2 Target::storageIdentifier and = Target::componentIdentifier don't use the custom types for = StorageIdentifier and ComponentIdentifier. > =E2=80=A2 I think digests should have a type, so the = user can more easily restrict its format after choosing a digest = algorithm. > =E2=80=A2 Suggestion: Add nint to textKeys group. > =E2=80=A2 AuthenticatedManifest should probably contain = an authenticatedManifestVersion or similar. > =E2=80=A2 "Processor" might be confusing (=E2=80=9Cdoes = it mean CPU?=E2=80=9D). It also helps to occasionally run instances of formal languages through = some tool to check them=E2=80=A6 Apart from inconsistent use of names, most of the syntax errors stem = from the arcane syntax that CDDL is using for its workaround for not = having true enumerations (Section 2.2.2.2 of = draft-ietf-cbor-cddl-03.txt); this requires commas (or nothing) instead = of slashes, and an enclosing &, so with =C3=98yvind=E2=80=99s = suggestion, textKeys becomes, e.g.: textKeys =3D &( uninitialised: 0 manifestDescription: 1 payloadDescription: 2 vendorName: 3 modelName: 4 payloadVersion: 5 ) / nint And Processor starts off as: Processor =3D [ &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: = 5), (Of course, the same thing can be expressed as: Processor =3D [ &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: = 5), decrypt: 1 // decompress: 2 // undiff: 3 // relocate: 4 // = unrelocate: 5, Not sure what the intent is here; in the first case, I=E2=80=99d = probably also add a label, as in Processor =3D [ process: &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, = unrelocate: 5), I have attached a version that parses (I don=E2=80=99t think an = attachment will make it to the lists) but does not address any other of = =C3=98yvind=E2=80=99s suggestions. The other problem that should probably be addressed is that most rules = are unused =E2=80=94 there would need to be one cddl file for the = manifest, and maybe one for the COSE envelope. We simply don=E2=80=99t = have a good way in CDDL yet to say =E2=80=9CManifest goes through an = algorithm and turns up in COSE_Sign=E2=80=9D =E2=80=94 actually, in this = case this could be solved in part as the manifest turns up in cleartezt. I have included a dirty hack in the attached which I intend to fix. I=E2=80=99m CCing the CBOR WG to give an example for CDDL being used in = another WG. If you want to discuss a CDDL feature, please strike SUIT = from the list (and if you want to discuss a SUIT feature, maybe strike = CBOR from the list). Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_5C896E86-7EED-48AA-90F2-A78D22C86E90 Content-Disposition: attachment; filename=suit.cddl Content-Type: application/octet-stream; x-unix-mode=0644; name="suit.cddl" Content-Transfer-Encoding: 7bit AuthenticatedManifest = [ authenticatedManifest: COSE_Mac / COSE_Sign, text: bstr .cbor textMap ] COSE_Mac = bstr .cbor what ; these are lies; FIXME COSE_Sign = bstr .cbor what ; these are lies; FIXME textKeys = &( uninitialised: 0 manifestDescription: 1 payloadDescription: 2 vendorName: 3 modelName: 4 payloadVersion: 5 ) / nint textMap = { * textKeys => tstr } Manifest = [ manifestVersion : 1, digestInfo : DigestInfo, ; textReference is the digest of the associated ; text map in AuthenticatedManifest textReference : bstr, nonce : bstr, sequence : SequenceNumber, preConditions : [ * PreCondition ], postConditions : [ * PostCondition ], directives : [ * Directive ], resources : [ * ResourceInfo ], processors : [ * ProcessingStep ], targets : [ * TargetInfo ], extensions : { * int => bstr} ] ResourceInfo = [ type: &(payload:1, dependency:2, key:3, alias:4) indicator: UriList, ; where to find the resource size: uint / nil, ; size of the resource ; (nil when alias) digest: bstr, ; digest of the resource onode: bstr ; Node of the processing ; graph that the resource feeds ] ProcessingStep = [ process: &(decrypt: 1, decompress: 2, undiff: 3, relocate: 4, unrelocate: 5), ; decrypt: 1 // decompress: 2 // undiff: 3 // relocate: 4 // unrelocate: 5, parameters: bstr ; TBD: more detail needed inode: bstr, ; Node of the processing graph ; that this processor consumes onode: bstr ; Node of the processing graph ; that this processor feeds ] TargetInfo = [ componentIdentifier: [ * bstr], storageIdentifier: tstr, ; where to store the resource encoding: bstr / nil, ; the format of the resource ; (nil when alias) inode: bstr ; Node of the processing graph ; that this target consumes ] PreCondition = IdCondition / TimeCondition / ImageCondition / CustomCondition PostCondition = ImageCondition / CustomCondition IdCondition = [&(vendor: 1, class: 2, device: 3), id: Uuid] TimeCondition = [&(installAfter: 4, bestBefore: 5), time: Timestamp] ImageCondition = [&(currentContent: 6, notCurrentContent: 7), digest: bstr / nil, location: StorageIdentifier] CustomCondition = [nint, parameters: bstr] Directive = [ int => bstr ] SequenceNumber = uint Timestamp = uint .size 8 Uuid = bstr .size 16 StorageIdentifier = bstr ComponentIdentifier = bstr ;;; XXX unused -- what is this for? UriList = { + int => tstr } DigestInfo = [ digestAlgorithm : uint, ? digestParameters : bstr ] --Apple-Mail=_5C896E86-7EED-48AA-90F2-A78D22C86E90 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_5C896E86-7EED-48AA-90F2-A78D22C86E90-- From nobody Wed Jul 4 13:58:57 2018 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 C6201130DD9 for ; Wed, 4 Jul 2018 13:58:55 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001, URIBL_DBL_ABUSE_REDIR=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 4qCm_RCfJMiG for ; Wed, 4 Jul 2018 13:58:53 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AD130DC0 for ; Wed, 4 Jul 2018 13:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w64KwnEt006858 for ; Wed, 4 Jul 2018 22:58:49 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41LYHs0fjzzDWnc; Wed, 4 Jul 2018 22:58:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann Date: Wed, 4 Jul 2018 22:58:47 +0200 X-Mao-Original-Outgoing-Id: 552430725.634372-b9e78216871231a16d3e17be93bc9793 Content-Transfer-Encoding: quoted-printable Message-Id: <7BDC3C3C-EF18-45A1-8CB6-3F73587515FD@tzi.org> References: <153057436348.16456.1958103142708217308.idtracker@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Cbor] New Version of draft-ietf-cbor-cddl-03.txt: ten days to Montreal IETF X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 20:58:56 -0000 As you may have seen, the authors finally generated an updated version = of the CDDL spec. Please see the delta in: > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-03 This is supposed to address all the issues in https://github.com/cbor-wg/cddl/issues except for: one that is marked =E2=80=9CCDDL 2.0=E2=80=9D (for the = freezer), one editorial fix needed that doesn=E2=80=99t have technical = consequences, one comment about the tool, and three issues marked = =E2=80=9Chelp wanted=E2=80=9D. Those three issues raise some questions that the authors could not = simply solve without some direction of the WG where we should go: =E2=80=A2 Which data model do .eq and .ne use? (#18) =E2=80=A2 IANA registry for control operators? (#17) =E2=80=A2 Specify group matching (#14) I intend to bring up one each of these on the mailing list in the next = few days, when people are back from July 4th. If you have other comments that have not been addressed, of course we = also would like to hear them (again. please, if needed). We do want to stay in the frame of CDDL 1.0 =E2=80=94 please consult = draft-bormann-cbor-cddl-freezer (which I haven=E2=80=99t updated though) = to check whether any new idea has already been frozen for 2.0. The plan is to have a =E2=80=9304 ready at the start of the IETF meeting = in Montreal; an editor=E2=80=99s copy (which already has some fixes = relative to =E2=80=9303) is always at: https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html and the diff for that is at: = https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -cbor-cddl.txt&url2=3Dhttps://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.= txt or https://is.gd/cddl_editing_diffs if your mail reader can=E2=80=99t do long URIs. In any case, enjoy the rest Independence Day (or simply a soccer-free = day, if you live outside the US). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 5 14:23:38 2018 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 58BCE127148 for ; Thu, 5 Jul 2018 14:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EVE7QYUYNow for ; Thu, 5 Jul 2018 14:23:32 -0700 (PDT) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (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 AD05C124D68 for ; Thu, 5 Jul 2018 14:23:32 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id bBitf3EK845IEbBitfy3IA; Thu, 05 Jul 2018 14:23:32 -0700 From: Laurence Lundblade Message-Id: <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4C52B2F9-551E-443B-A4E7-100CDFE5B8A5" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 14:23:31 -0700 In-Reply-To: <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfK0eLSInAoUGaGa+EAFjG0DgMyNipZWasypY6IDbNUYjc0yExNndXGVy90I8AuI/KvTeVLAyVa1aPvzTFvWp6KNd/tMjE3Ld0GEE1sYtXEJQ+xfJ9Bvq mOoRzoLKLsrGccrajNfnGCDLv5aqMEGPcCzyM1a5qXHnSbT8nf/3Zc0UoCL+gC+aStnVoegKwZMMrQ== Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 21:23:37 -0000 --Apple-Mail=_4C52B2F9-551E-443B-A4E7-100CDFE5B8A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Carsten, I=E2=80=99m definitely after tightening up tag 1 here (and exploring as = an example around canonicalization, variation and options in CBOR). = I=E2=80=99m not a time geek, nor do I have any use cases other than tag = 1. I think tag 1 time probably covers the vast majority of use cases for = time in CBOR protocols. I=E2=80=99ve updated the PR = so floating point is no longer removed, but still discourage its use = unless greater than 1 second precision is needed. The interop problems I = see with floating point are: - Small CPUs like ARM Cortex M0 and ATmega16/32U4 do not support it - Floating-point is extra work for a CBOR implementor (It was for me = anyway) There should be as few choices for the implementor as possible and those = there are should be clear. So the choices in the PR = are mostly a) 64 or 32-bit = integer support, b) support negative time (to sort your Jimi Hendrix = albums), c) support double if you need microsecond time. I do think there should be clear requirements for each tag, maybe even = canonicalization requirements per tag, especially for a tag that will be = widely implemented and used like tag 1 and especially for something as = problematic as time. You=E2=80=99ll probably say I have way too much time on my hands, but = there=E2=80=99s a tag 1 implementor FAQ below. LL Tag 1 Implementator=E2=80=99s FAQ Q: I just want to implement the minimum, what should I do? A: You should support 64-bit unsigned encoding. This will cover just = about every use case because it works from 1970 until over 500 billion = years in the future and 1 second resolution is enough for most human = activity. Note that time values up to 2106 will be encoded as 32-bit = integers even though 64-bit integers are supported because only 32-bits = are needed to count seconds up to the year 2106. Q: I=E2=80=99m implementing on an 8-bit CPU and 64-bit integers are = really a problem. A: You can support just 32-bit integers in that case, but they will stop = working in 2106. Q: Why 2106 and not 2038?=20 A: Because CBOR encodes positive and negative integers with different = major types and thus is able to use the full 32-bits for positive = integers. Q: What if I need time values before 1970?=20 A: Implement 64 or 32-bit negative time values, but note that there is = no clear standard for this as POSIX and UTC time are not defined for = this time period. If your implementation assumes every days is 86,400 = seconds and follow the rules for leap years, you should have accuracy to = within hours, if not minutes. Q: Is Tag 1 better than Tag 0 for time values? A: In a lot of ways it is, because it is just a simple integer. It takes = up a lot less space. It is a lot simpler to parse. Most OS=E2=80=99s = have the ability to turn POSIX time into a structure of month, day, = year, hour, minute and second. Note however that POSIX time has a = discontinuity of about once every year for leap second adjustment. Q: What is a leap second? A: It actually takes the earth about 1 year and 1 second to revolve = around the sun, so 1 extra second has to be added almost every year. UTC = Time handles this by counting the seconds from 0-60 (not 0-59) in the = last minute of the year. This standard uses POSIX time which can be said = to handle this by the clock stopping for 1 second in the last minute of = the year.=20 Q: Do I have to implement floating point time? A: No. There are not many use cases that need it. However for maximal = interoperability, it is good to support it. Q: When should I use floating point? A: Only if you need time resolution greater than one second. There is no = benefit otherwise. 64-bit time can represent time +/-500 billion years = in the same number of bits, so floating point time is unnecessary for = very large times scales. Q: What resolution to I get with floating point? A: It varies over the years. For 1970 to 1971 you get almost nanosecond = accuracy. For the current century, 2000-2099, you get microsecond = accuracy. 285 million years from now, it will be less than a second and = the 64-bit unsigned representation will have more resolution. This is = because a double only has 52 bits of resolution. Q: Should I implement single or double floating point? A: If you are going to use floating point you should always implement = double. Single has no advantage over 32-bit integers. It provides less = range and less precision. It has only 23 bits of resolution. It is of = course good to support decoding of single in case some one sends you = one, but there no point to ever sending a tag 1 encoded time value as a = single. Q: Can I disallow floating point time in the definition of my protocol? A: Yes. This is a good idea if you do not need resolution less than one = second. It will make implementations simpler and more compact. Note that = while most CPUs do support IEEE 754 floating point, particularly small = ones do not. Q: What I=E2=80=99m transmitting thousands of time stamps and space is a = problem? A: If you want to maintain 1 second resolution, there is really no more = compact way to transmit time than tag 1 32-bit or 64-bit integer. If you = wish reduce resolution, use a different time, perhaps one that counts = days rather than seconds.=20 =20 > On Jul 2, 2018, at 12:10 PM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 > the representation of time is indeed one of those eternal issues in = representation formats. >=20 > Tag 1 is relatively well-defined as it is, and I don=E2=80=99t think = we want to change that. > Instead, new tags have been defined for time (and there, of course, = also has been tag 0). >=20 > Not all tags need to be defined in the CBOR base document. > In particular, in this round we are aiming to collect the stable parts = of CBOR, as opposed to putting in more bells and whistles. > We are *not* defining a new version of CBOR (there are no versions in = CBOR). >=20 > New bells and whistles can be added by just registering tags. > The set of registered tags can at any time be examined at: >=20 > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml >=20 > Looking for =E2=80=9Ctime=E2=80=9D, we see (apart from 0 and 1): >=20 > 1001 map extended time [draft-bormann-cbor-time-tag-01] >=20 > This tag has been registered a while ago and already has been = implemented in some environments that care about precise time (e.g., = Haskell with its picosecond-based time). >=20 > On to the specific changes that you propose: >=20 > =E2=80=94 getting rid of floating point time =E2=80=94 I would expect = that is in active use, but I haven=E2=80=99t done a survey. It = definitely is allowed by RFC 8392 (which uses Tag 1 in an indirect way). = Floating point time has the weird property that its resolution gets = lower the further away you get from the epoch. But otherwise, it is = fine. Currently, of the 53 bits of resolution of a binary64, 31 bits = are taken for the integer part, so 22 bits remain for the fractional = part. That will change to 32+21 in 2038 =E2=80=94 a date that most = people who work with Posix times are aware of, as the integer time_t no = longer will fit in a signed 32-bit int then. So I don=E2=80=99t see any = deadly interoperability problems that would stop us from continuing to = support floating point valuess in tag 1. Any specific application can = be more selective, if desired. >=20 > =E2=80=94 being more explicit about negative values (int or float). = Good point. >=20 > - requiring support for =E2=80=9Cpositive=E2=80=9D (I think you mean = unsigned) integer values. Just as an application can rule out floats in = its usage of Tag 1, it could do so for integers. A generic CBOR = implementation that doesn=E2=80=99t support integer values here could be = considered not so bright, though. (CBOR is more about interoperability = than about conformance, anyway.) >=20 > =E2=80=94 comments about serialization (encoding). I don=E2=80=99t = think a Tag should define that level of requirement. If an application = wants to use minimal-size encoding, so be it, but that=E2=80=99s none of = the business of a Tag. >=20 > So, in summary, I=E2=80=99d say let=E2=80=99s pick a good way to = handle negative numbers (being aware that there is no really good way). = Probably MJD-based interpretations. But let=E2=80=99s talk to = astronomers here=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Jul 2, 2018, at 20:29, Laurence Lundblade = wrote: >>=20 >> I think that the more we can reduce implementation / encoding options = and variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about. >>=20 >> Here is a PR for new text for epoch time (tag 1). =20 >>=20 >> I don=E2=80=99t know what the philosophy is for compatibility with = RFC 7049. This proposal breaks it. Maybe it should be a different tag = value or such because of that. >>=20 >> The big break is disallowing floating point values because you can do = better in a number of ways by defining a new tag for time expressed in = micro or nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here). >>=20 >> The general decoder implementor and protocol designer is left with = only two choices: >> - Support 64-bit time values or not >> - Support negative time values or not >>=20 >> The protocol designer should of course make a call on these choices = so there aren=E2=80=99t interop problems. >>=20 >> There=E2=80=99s more detailed rationale in the PR comments. >>=20 >> I=E2=80=99m curious what you think. :-) >>=20 >> LL >>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_4C52B2F9-551E-443B-A4E7-100CDFE5B8A5 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_037F378E-7E52-4E7F-A07F-BAA9512A117E" --Apple-Mail=_037F378E-7E52-4E7F-A07F-BAA9512A117E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Carsten,

I=E2=80=99m definitely after tightening up tag 1 here (and = exploring as an example around canonicalization, variation and options = in CBOR).  I=E2=80=99m not a time geek, nor do I have any use cases = other than tag 1. I think tag 1 time probably covers the vast majority = of use cases for time in CBOR protocols.

I=E2=80=99ve updated the PR so floating point is no longer removed, but still = discourage its use unless greater than 1 second precision is needed. The = interop problems I see with floating point are:
 - Small CPUs like ARM Cortex M0 and ATmega16/32U4 do = not support it
 - Floating-point is extra work = for a CBOR implementor (It was for me anyway)

There should be as few = choices for the implementor as possible and those there are should be = clear. So the choices in the PR are mostly a) 64 or 32-bit integer support, b) = support negative time (to sort your Jimi Hendrix albums), c) support = double if you need microsecond time.

I do think there should be clear = requirements for each tag, maybe even canonicalization requirements per = tag, especially for a tag that will be widely implemented and used like = tag 1 and especially for something as problematic as time.

You=E2=80=99ll probably = say I have way too much time on my hands, but there=E2=80=99s a tag 1 = implementor FAQ below.

LL



Tag 1 Implementator=E2=80=99s = FAQ



Q: I just want to implement the = minimum, what should I do?
A: You should support 64-bit = unsigned encoding. This will cover just about every use case because it = works from 1970 until over 500 billion years in the future and 1 second = resolution is enough for most human activity. Note that time values up = to 2106 will be encoded as 32-bit integers even though 64-bit integers = are supported because only 32-bits are needed to count seconds up to the = year 2106.

Q: I=E2=80=99m implementing on = an 8-bit CPU and 64-bit integers are really a problem.
A: You can support just 32-bit = integers in that case, but they will stop working in = 2106.

Q: Why 2106 and not = 2038? 
A: Because = CBOR encodes positive and negative integers with different major types = and thus is able to use the full 32-bits for positive = integers.

Q: What if I need time values = before 1970? 
A: = Implement 64 or 32-bit negative time values, but note that there is no = clear standard for this as POSIX and UTC time are not defined for this = time period. If your implementation assumes every days is 86,400 seconds = and follow the rules for leap years, you should have accuracy to within = hours, if not minutes.

Q: Is Tag = 1 better than Tag 0 for time values?
A: In a lot of ways it is, = because it is just a simple integer. It takes up a lot less space. It is = a lot simpler to parse. Most OS=E2=80=99s have the ability to turn POSIX = time into a structure of month, day, year, hour, minute and second. Note = however that POSIX time has a discontinuity of about once every year for = leap second adjustment.

Q: What is = a leap second?
A: It = actually takes the earth about 1 year and 1 second to revolve around the = sun, so 1 extra second has to be added almost every year. UTC Time = handles this by counting the seconds from 0-60 (not 0-59) in the last = minute of the year. This standard uses POSIX time which can be said to = handle this by the clock stopping for 1 second in the last minute of the = year. 

Q: Do I have to implement = floating point time?
A: No. There are not many use = cases that need it. However for maximal interoperability, it is good to = support it.

Q: When should I use floating = point?
A: Only if = you need time resolution greater than one second. There is no benefit = otherwise. 64-bit time can represent time +/-500 billion years in the = same number of bits, so floating point time is unnecessary for very = large times scales.

Q: What resolution to I get with = floating point?
A: It = varies over the years. For 1970 to 1971 you get almost nanosecond = accuracy. For the current century, 2000-2099, you get microsecond = accuracy.  285 million years from now, it will be less than a = second and the 64-bit unsigned representation will have more resolution. = This is because a double only has 52 bits of = resolution.

Q: Should I implement single or = double floating point?
A: If you are going to use = floating point you should always implement double. Single has no = advantage over 32-bit integers. It provides less range and less = precision. It has only 23 bits of resolution. It is of course good to = support decoding of single in case some one sends you one, but there no = point to ever sending a tag 1 encoded time value as a = single.

Q: Can I disallow floating point = time in the definition of my protocol?
A: Yes. This is a good idea if = you do not need resolution less than one second. It will make = implementations simpler and more compact. Note that while most CPUs do = support IEEE 754 floating point, particularly small ones do = not.

Q: What I=E2=80=99m transmitting = thousands of time stamps and space is a problem?
A: If you want to maintain 1 = second resolution, there is really no more compact way to transmit time = than tag 1 32-bit or 64-bit integer. If you wish reduce resolution, use = a different time, perhaps one that counts days rather than = seconds. 
 






On Jul 2, 2018, at 12:10 PM, Carsten Bormann <cabo@tzi.org> = wrote:

Hi Laurence,

the representation = of time is indeed one of those eternal issues in representation = formats.

Tag 1 is relatively well-defined = as it is, and I don=E2=80=99t think we want to change that.
Instead, new tags have been defined for time (and there, of = course, also has been tag 0).

Not all tags = need to be defined in the CBOR base document.
In = particular, in this round we are aiming to collect the stable parts of = CBOR, as opposed to putting in more bells and whistles.
We = are *not* defining a new version of CBOR (there are no versions in = CBOR).

New bells and whistles can be added = by just registering tags.
The set of registered tags can = at any time be examined at:

https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml<= br class=3D"">
Looking for =E2=80=9Ctime=E2=80=9D, we see = (apart from 0 and 1):

1001 map extended = time = [draft-bormann-cbor-time-tag-01]

This = tag has been registered a while ago and already has been implemented in = some environments that care about precise time (e.g., Haskell with its = picosecond-based time).

On to the specific = changes that you propose:

=E2=80=94 getting = rid of floating point time =E2=80=94 I would expect that is in active = use, but I haven=E2=80=99t done a survey. It definitely is allowed by = RFC 8392 (which uses Tag 1 in an indirect way).  Floating point = time has the weird property that its resolution gets lower the further = away you get from the epoch.  But otherwise, it is fine. =  Currently, of the 53 bits of resolution of a binary64, 31 bits are = taken for the integer part, so 22 bits remain for the fractional part. =  That will change to 32+21 in 2038 =E2=80=94 a date that most = people who work with Posix times are aware of, as the integer time_t no = longer will fit in a signed 32-bit int then.  So I don=E2=80=99t = see any deadly interoperability problems that would stop us from = continuing to support floating point valuess in tag 1.  Any = specific application can be more selective, if desired.

=E2=80=94 being more explicit about negative values (int or = float).  Good point.

- requiring = support for =E2=80=9Cpositive=E2=80=9D (I think you mean unsigned) = integer values.  Just as an application can rule out floats in its = usage of Tag 1, it could do so for integers.  A generic CBOR = implementation that doesn=E2=80=99t support integer values here could be = considered not so bright, though.  (CBOR is more about = interoperability than about conformance, anyway.)

=E2=80=94 comments about serialization (encoding).  I = don=E2=80=99t think a Tag should define that level of requirement. =  If an application wants to use minimal-size encoding, so be it, = but that=E2=80=99s none of the business of a Tag.

So, in summary, I=E2=80=99d say let=E2=80=99s pick a good way = to handle negative numbers (being aware that there is no really good = way).  Probably MJD-based interpretations.  But let=E2=80=99s = talk to astronomers here=E2=80=A6

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


On Jul 2, 2018, at 20:29, Laurence Lundblade = <lgl@island-resort.com> wrote:

I = think that the more we can reduce implementation / encoding options and = variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about.

Here = is a PR for new text for epoch time (tag 1).  

I don=E2=80=99t know what the philosophy is for compatibility = with RFC 7049. This proposal breaks it. Maybe it should be a different = tag value or such because of that.

The big = break is disallowing floating point values because you can do better in = a number of ways by defining a new tag for time expressed in micro or = nano seconds from the epoch in a 64-bit integer (perhaps as suggested = here).

The general decoder implementor and = protocol designer is left with only two choices:
=   - Support 64-bit time values or not
=   - Support negative time values or not

The protocol designer should of course make a call on these = choices so there aren=E2=80=99t interop problems.

There=E2=80=99s more detailed rationale in the PR = comments.

I=E2=80=99m curious what you = think. :-)

LL


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

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

= --Apple-Mail=_037F378E-7E52-4E7F-A07F-BAA9512A117E Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=PastedGraphic-2.png Content-Type: image/png; x-unix-mode=0666; name="PastedGraphic-2.png" Content-Id: <76EE6EA1-F82D-4532-955E-A0C188AEE9D3@attlocal.net> iVBORw0KGgoAAAANSUhEUgAAAp8AAADsCAYAAAAywc1OAAABfGlDQ1BJQ0MgUHJvZmlsZQAAKJFj YGAqSSwoyGFhYGDIzSspCnJ3UoiIjFJgv8PAzcDDIMRgxSCemFxc4BgQ4MOAE3y7xsAIoi/rgsxK 8/x506a1fP4WNq+ZclYlOrj1gQF3SmpxMgMDIweQnZxSnJwLZOcA2TrJBUUlQPYMIFu3vKQAxD4B ZIsUAR0IZN8BsdMh7A8gdhKYzcQCVhMS5AxkSwDZAkkQtgaInQ5hW4DYyRmJKUC2B8guiBvAgNPD RcHcwFLXkYC7SQa5OaUwO0ChxZOaFxoMcgcQyzB4MLgwKDCYMxgwWDLoMjiWpFaUgBQ65xdUFmWm Z5QoOAJDNlXBOT+3oLQktUhHwTMvWU9HwcjA0ACkDhRnEKM/B4FNZxQ7jxDLX8jAYKnMwMDcgxBL msbAsH0PA4PEKYSYyjwGBn5rBoZt5woSixLhDmf8xkKIX5xmbARh8zgxMLDe+///sxoDA/skBoa/ E////73o//+/i4H2A+PsQA4AJHdp4IxrEg8AAAFiaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQu MCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1y ZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg ICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAg ICAgPGV4aWY6VXNlckNvbW1lbnQ+U2NyZWVuc2hvdDwvZXhpZjpVc2VyQ29tbWVudD4KICAgICAg PC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+Cm7M3i4AAEAASURB VHgB7J0FfBTXE8cHQoI7JLhrKe7uLkWKtUApUpz+geJQrLgXKxR3d3d3l+KuwR1CgP7n9y677F1O k0saYIYPub3dZ/u93bvZ90bC/ctCIkJACAgBISAEhIAQEAJCIBQIhA+FPqQLISAEhIAQEAJCQAgI ASGgCIjyKReCEBACQkAICAEhIASEQKgREOUz1FBLR0JACAgBISAEhIAQEAKifMo1IASEgBAQAkJA CAgBIRBqBCJY9nTi0lM6e+2F5W55LwSEwBdCIGOK6OpM5D7/Qj5QOQ2XCdQsloQWbb/lcj2pIASE QNAIFMoaj5LEj6xXDqR87jr5iOZvvKYXkA0hIAS+LAJ1yqRQJyT3+Zf1ucrZOE+gWpHENHbxBecr SEkhIASCRSBR/EhmyqcsuwcLp1QWAkJACAgBISAEhIAQcIWAKJ+u0JKyQkAICAEhIASEgBAQAsEi IMpnsPBJZSEgBISAEBACQkAICAFXCIjy6QotKSsEhIAQEAJCQAgIASEQLAKifAYLn1QWAkJACAgB ISAEhIAQcIWAKJ+u0JKyQkAIfHEEokX2pFSJo1OkiIGCf/zn5+oVwYPSJYtB8WNH+s/HIgMQAu4k IPedO2l+fm2J8vn5fWYyYiEQagSiRo5AlQsnpipFklAEj3Ch1m9odtS2Vjqa2TMP/Vg2eWh261Rf xXJ609RuuWlQiyxOlXdUKHu6ODSnT37qVP8bR0W/+uN5MsWlkrkTUMGs8W0+mMSO7kXFciZQ5b5J GVMxE8bOXTpf033Xu2lmmt07P2VIYbpGnCP0ZZcKe4/6XzZvOTsh8NkQKJAlPnX8IT3FjxVRjXnH 0fv07OW7z2b8zg40XIBOrb06Wy80yoULGJSrY8OPXCFWms5ceUr7Tj3Uh5omaTRK7hOFInrKvIMO xcpGmqQxaESbbPqR3ScfUpfxJ/T32saoX7NT6iTR1Fu/dx+pZNttJIw1OvZftWtae7VfOnSPuvO+ C8/fLwX4QSZKJA9KxvfeuWvPQvdkwmhvonyG0Q9GhiUE/ksCDSuloiaVUpKf/8f/chjSdxAJ5P0m LjUsn5y2HY1spnyu3n2Hbt5/Tbd8Xwex5a+jWpSIHupE3777QFBECmaOq0wfHjx5qwP4NlUspXg+ e+lPMaN5kpen6SlGGOuIvroNa/fdx3+Jmg09QvFiedGJ80+/Oia2TliUT1tkZL8Q+IoJ4Md06ppr dOTcYxrXIYdTJJInjErFsvvwl2xEuvfoLW08eJeMP9Y50sehLGljUdRIEejy7Ze09ZAvvXv/wazt 3DxDkJl/1KPxLMGxS89o93Ff+pe/vCEZeTYvS9rYlDBuRLrz8A0dOvuErt7+lAq4dJ6EFCWyB63Y cYvyfhuPcqSPTU9e+NNmHsfDp36mRvhvmiQxqGCWeOTJs3/beTbXkSSMF5mK8Hkd/OcRQSkpk9eH 9vBM2MEzj1RVR+fliIuj87IcX7l8iSh61Ai08cA9fSY6S5rYlJGXffF5xYnhSZkCloATczq7qkWT 0I17r+no+ceqHmZfYEJxi5VQTRyNwVm2WntfyiuUzyOsMJRk8wcswRuzgpXLn1Cd5qbDvvQ9p+vU BJ+NNcax1BK9DyVPEIUePX2n7o/7j9+SxnbdnrtUq1QyisX33qTll9W9EZntkItk96aUiaLSB9Zi rt15RduP3CP/DwE3BXfq6PpydH3aGpd2PvauDeO98ezFOyqey4cSxIlEJy494Xv3gdaEeg3N+86T r+8SuRNSOp7phxzn75Jdx3zVNv44w1UvzBtJvKOw+YU3Xb/3kvYHrCRE9PKgSoUS04cPH2nFzluU mx/4bN13Kfm7MW5ML7p88yU9fv7pO88eW/SvXRuOvtOMY/1ctkX5/Fw+KRmnEAhFAqPnn1e9peXl R2cEyt6wVlnULNHrtx/UElOqJFGp35TTqnqHHzNStcKJWJH8lzAT4MFrUT+USkothh2hV2/eqzI9 GmaicvkS6N3VKpmUhsz1pJX8xd7q+3RUl8sbBT/GIxdepOXbb6rdzaulIh92zEnPDjpVCpoUAxyo WzIJ/djnAL187U8FWOns/0tm8oxgWnauXzoZPXJgSgDFrk2N1LQvQ2zKwwqtR4RwPMvloZRPR+fl iIsz52U8Z2y3rZmGYkT1pAs3XtCJiyYziMqFElF5Zjd9nQdlSxOLsrGSD0mXNDr9Vjc97eEfTCif sEds+31aunDzha4cODMGZ9iqDr/AP5sP31fKZwV+6NCUTygeZXL70DteGdh25L6Z8mmNMZSMoa2z sGLppRPC9Vzxt52ksc3PD16F+PqELNp2kx90ItCQllkoYTxzZ7N6ZZNR25HH1IOHo+vL0fVpb1wY h6NrQ7s3dqeNSd+kiMEPPqbzw7mNXXpZ5xWa991bvw80sl1Ovg9iqpWbCDxzXZu/S+r0eqFm/FMm iu6QK87dKDkzxlHfAUcvPNWVz7gxI1K7WmlVsbV771KDcils3net+PsD3023H7ymvSdND8KO2KJh 7dqw951mHOfntC3K5+f0aclYhUAYJVCjaFKleA6YeY7W7r1N3jz7kSR+FDVa/EBC8bzGs29thh8h D56V6PlzJsrJilytUslp2qrLVJhnFqF4wm5u2tprPKv5mMrmM/24w/EDP2Y41n/mWbp48zlVLJiY 6pVJxj8IaWjPiQdmM6wV8yagiSuu0BNWKtuxMxF+JDAjs2bXLWrDSiwUz/3/PKZFW29SWS4LJcIk 9h2q8meKQzd4uXrF7rt0l2denTkve1ycOa+gfNxjl1yiuqxUY7bun2vPae6mm2aznMY2nRmDcfba FttV/IDwpcqB0w8JD1SpEkdje84YdImvv8LZvNUD1jaeOX/+2vTwZOv8YfPXqV4GpXhiBm7a6isU LYqnmcKKulA8F2+/pdp7yrOIfZpkUornrhMPaRJfzzGjReD75htKzeP4qWIK+nPBBbJ3fTm6Pmes vmx3XM5cG9o5Y+wnrzyjUfwwWC5vQiqQOQ7fn0mV8onzD837DjbOUDxvPXhDDfih8+O/HylPpnj0 5LnpQa1z/fQOuWrn5cqr3Heu0CISq3PXeElpISAErBB4/8G0lFQ6j48KW4TlRMy0QUrmNCl3m3l5 8j3PVsKOdCf/oEKypDZ5fxbNHl+938dL2bPXX6Xz15+pH9f1++6wUmqaxVyz/x5tPXyPbrICOGnZ RXr0zE85zmTlpXijjFx8kWatu0qrd92mfadNS+OJ4rIy7BOVknpHVkUHzzpLUCr68szs4XNPjNVt br94488zTkdpwaZrtJOX8Jw5L3tcXD0vmwOzOACHhiu3X6m9vvw5YJkWCpM1cXUMtthaa/tL2ffO /wPtCFhCLsvXN6RSAdM1ueHgPYenmYgfwtIGOCWNmHdemUbsOOpLbUYcMas7a+MNGsUrDlNXXibv 2BHp2wDTiWFzz9HVOy/o+IUnPLN9XdUpxA90EHvXl6Pr09G4XLk2fNkWtt2oY+r+/Gv5JTU2zPJi eTu077v3700mCd5s/lOWPycPj/A82/hArbAkZZMTZ7iqE3Dxj9x3rgGTmU/XeElpISAErBCYwT+K 2dPHoty8NI2wRccvPqVBs8+qZa5kCUwKHxyY8N8o0aOYvoKSBSiFJy8HNsjXFMYrd17qVbF0f8P3 jZrVxHKWUe4/fqO/fcw2n5BIbKuplXvxyt9spvSBbg/6yY5Ob8CwcffhWzPbUWfOyx4XZ87rISvY ISnOjMHYvy22xjJf4jYenGDWgJnyZTtv86x9LMLDCB5gkviY7AptnXcitruFvOHl4GusRNqSU2wn qQkUQwj6wEOWJjfvmR4qfPhhCl7i9q4vR9eno3E5c21o1yecrvzYPhZijIgR0St8qN93l249p/UH fakcPyh05mgdrdkcZ8b6GzR3wzVylqvGO6RenWFr7PtLvO9E+TR+wrItBIRAkAhgprLu7/upSqEk VKNYImX7NLRVNt63l969Myl1K9mhYn/ATKTWyQ024Id8hDbJEi5c4MWYd/6mYxHZztIokdkpCfLs tXPhn94HOGl4sb0efrg1RyZjm65sO3NedrkE8by0cXvyjE5wxV1sgzuOsF7/6NlHhIcW2DT24KVv eMBvOfyA/ANm2eyN/2OAf0l4Xn8OuMztFVfH/AOiTETkJANGwUMU5Dkre7gO7F5fDu67eDFND222 xuWua+O/uO/+mHqaNuy7SzWKJ1HmDC2rpab7T/zocYAi74irkTm2tXvOi+293SHuYuuOsfxXbQT/ 2+u/Grn0KwSEQJgh4MlfyrBTm7nuCv0yxLSciKd72LZdD/CqxiwIlquN/6/dNc3kXGd7UEjR7PEo fMC3EuKLIl7l9YCwQIWzxFVKI8rBy1ZbyrzEHqTOyJ1HphlRxLjMlSGuqoJ28mQ0X7Z3pi2Ucea8 7HIJ4nk9YcUDki55dPWaLEFUyvtNHLWt/fFnD1xI3IAYrdp+y1d3sbVs90t7D+/yLUdN3ttZUplM RTY5seQODrfYyQSC6w52lJrAztmWaHW8uE7ODJ8+2yJsawo5e910zdu9vhzcd1oftsblrmsjtO87 ODPi4fIQPzAgNusqdgaCpE8WXf8sHHFVFQx/oOxDEMVAy4RWwxDhQCsq951GwvGrzHw6ZiQlhMBX RwAhX4oGOFVoJz+0dVY10zOEl9OvByz/acf+6pSbrnAYmDPs4JKRv+Qhd9jgHx7mS7beoO/Y+7ws O/ZE5h/Tf669oKi83J4zXSxax+GClrFn71J2tKjI9ln4YZ/WPS+HUnrLCmJsmrf5Ji3acpMq5U+g ZlMndMxFl9ieEYoofmTgxe1s0GZfVj7hrZqD++3fLDMdu/hEOSZE8tS+Bl2b1XDmvOxxcea8krNi aSknLz+jFByup9l3qahI1njqR1WbmeG5Y1X8NrOHgOeY9jmVd/uYRRfUPuMfZ8ZgLP81b2/lpfeq 7DgHuc+mGicNy+T2uNzj6w5B6uGUM4CvO4QIgw0ygtMXb2U91BdspjezF30pdhob0Oxb2nrsIcVj xzk4vUGmrrmiXu1dX85cn/bG5cy1Ye36VAMz/Ant++4h2582r5aGQ5H50su37/WHy/McHcJZrobh q82z15+r1RlEmZjVM6+yXU8SPxJ/H35UDoxQdiFy35k4OPNXZj6doSRlhMBXRiCpd1TKyh6j2uwi Th+hVLAvKudCt5SD7LRThm2sfquTTimRF2+9pG4TT6timN3sNOGkUkaLZItPzaumovrsqY64d1e4 HOT8jef0++QzbC/mr7x5C7NSBVtMeLLD2aLj+JPsYf6WvmVlCgoAZlSX7bxDvbmOJvCGh2jL4aZt 05qndqwfL8ed4x8hZBsp8G1cVkCfUX92PoJoS53qjeEPwulAtFftkDPnZY+LM+el9am9ou+pHB0A P6RQvvGZwHlr4OxzaljaOew5cV959GNndla2o3CaVIjWjvbqzBhQT+Nnjy3KfSnyjpUKiDHJwvGL j9U1iP2r2YREU/j9OVYtQoi91a4/K9fLIL7GdvK1jFlGXNvJ+OFhMcejxYyqNbboYyg/5MFUBQ9H lfnBTIu2gDBL2gOXvevLmevT3ricuTa060h7xbixzI4waNp/7AvN++4qPwR7sUlK0yopVSgkOD7N 2nBdxfvFWJzhqp2P9goFetSii/SBzSwQ+gpxiDvzdxoeuLHv40fT9WLrvrP8jJ1hi7Fa1sO+dwG2 tdox7PscJRzfNCaDqoDRG2NzfY4nJGMWAkLAPoE6ZVKoAlrMQvulnT+K5Sgf9tJ9waFnHj//5CRh bCE6zxzE4WDb9srED3AgMob40drAzAPyzePHwNJ+jnUxFcbJ0g4PMTnhsWyUODEismLxQY8xaq2M sbwX2975s0e/+bflpxL2zssZLvbOy1bfCOYPJxYtTirKWQbtRwBxxKQEL01stWdvDK6w1foJy69b /iyuUmHaGyMClUOBMl5nmOHyBGeL6wlB+z/yxRGgg5AtxvgsYE6CByvNQccWW21seMjwiRtZ2Xm+ ZAckS3Hm+rJ3faI9a+My9mPv2rB2ruAB0ew9tbZC875DuDcvDqsGW0/LzwvjccTV2nlhXxx+aMZs NgQmQuH5orA8T8v7zt5nbI+trXqOvq/U4MLYnwEtsvBKTXx9VNp6k75DNoSAEBACQSHw1u89L8fb j3kIpw38tyfWlE6t/HOui//WBErCRysOINZ+eCyVY2tljH1YKnXGY9i2d17OcLF3Xrb6NmZtwhis lYMdrqVYK4cy9sbgClvL/j7X98YsQto54OHD2rViqXzYYgyF05hZCu3aYqv1CQX4ToDdqLbP+OrM 9WXv+kRb1sZl7MPetWHtXC15aG2F5n2HJXZ74oirtfPCPk3xRNt42PhIZvN3qkvL+87eZ2yPra16 1q5Be+caFo/JsntY/FRkTEJACAgBISAEhIAQ+EIJiPL5hX6wclpCQAgIASEgBISAEAiLBET5DIuf ioxJCAgBISAEhIAQEAJfKAFRPr/QD1ZOSwgIASEgBISAEBACYZGAKJ9h8VORMQkBISAEhIAQEAJC 4AslECjU0gd239LCRXyh5yynJQS+agIIMQKBt6eIEPgaCSAUkC2P7K+Rh5yzEAhpAh58zyEslSaB lE/tgLwKASEgBISAEBACQkAICAF3EwgU5xOR+v81Bet3d1/SnhAQAmGAQLiAmc9/ZeYzDHwaMoT/ gkB4BIXnTDwiQkAIhA4B3HPhDDOfgZTP276v6C7/FxECQuDLJJDQx5QvXO7zL/PzlbNyTCBXFh86 ctp6XnXHtaWEEBACrhJIlzIWxYoZSa8mDkc6CtkQAkJACAgBISAEhIAQCGkConyGNGFpXwgIASEg BISAEBACQkAnIMqnjkI2hIAQEAJCQAgIASEgBEKagCifIU1Y2hcCQkAICAEhIASEgBDQCYjyqaOQ jS+NgP97fzpyeA+9fvXiSzs1OR8hIASEgBAQAp8tgUDe7o7O5J7vHdqzc6MqBrf5aNFiUK48hSlO nHiOqobZ4+fOnaQTxw5SzTqNzYKgYsCbN66kSJEjU6HCpcPs+G0N7O6927R31yZbh1XYg0qV69Dy ZbPp0cP71KJ1V5tlQ/LArZvXaPu2tfTwgS8lTZqCSpWtSjFjxg52lzeuXaaWTb+ngUP/phKlKgW7 PWlACAgBISAEhIAQCD4Bl5XPZYtn0vTJoylBgkT08d9/6emTx5wR6QM1bNyWmjbvGPwRubGFG9cv 04plc6hhk/9RdFaSbcnWTatpxtQxVO37BuTl6WVWbPrkURSLFevPUfk8e/oYTZ44XD+fJ48fkZdX JIoazRRqJ3y48Oq8tm1ZQw987/4nyueGdUvpj97t+eElLsWL70NrVy+iaVNG0+oNx/Vxy4YQEAJC QAgIASHw5RBwWfn8NyD35qKV+5SiBoWmR5dfWMkZQQV5dvCbTNnCDJ1z507R7BkTqPJ3de0qn2Fm wG4eCGb7jDN+VSvmpvQZM9PgYVPNeho3aYl6gDDbGUpvxozsQ1my5qTRExZQBI8I5Of3ltatWRRK vUs3QkAICAEhIASEQGgTcFn5tBxgbJ6xqlu/OR0+tJfOnjmmK5/v/Pxo+/Z1dOXSOUqYMAkVLFKa 4sXzMat+5tRROsw2ef7v/Ch/wZKU6dvs+nFH9Q8d2KnKZs2Rj7ZvXUvXrlygzFlzU/4CxdV+2Pod ObhbbW/dvJrixo1P2bhs8hRp9D5c3Xj+4hmtX7OYSpauzO1569U3bVjBs3belD1HfrVPG1uWbHlo y6aVdP36FcqbrwjlyFmA82l/pA1rF9MN3oex589fTG8HGxj3saP7yd/fn1KlSkcly1RRShmOwXZx Dc8MVqxUk+7xTOXO7espSpSoSsG0ZIvyzsrRQ7vpxcsXVLxEBVUlOON39LkZx4TzefDgPp/jd/o5 RowYiapWr28sRq9fv6Ktm1fRzRtXKWGiJFSmXHV13ihkj5dZI4Y3ly6epYMHdtCb16/5mslFefIW MRyVTSEgBISAEBACQiAkCQRb+cTgHj64p8bow0omBHahHdr8SM+fPaXUaTPSovnTaOKEITRkxHT6 NnMOVWbMqH40Z+YESpU6HYUPH17NnPboPYIqVanjVP2F86eo9t+zU8m9u7cpcuQoNGXSSGrU9H/U rGVn2swK4Z7dm1Vfq5bPIw8PD/KIECFYyuf1q5do+OAelDhxcp7lLaXaxp9JEwZT+gxZdOVTG5sf K9WwpYTAVKFz90G0cf1yVpQvsq1sdJrG+1q17UYNfm6jynT5rTEd2L+T0qfPROF5vHNmjKflS2fT hL+XquN3+TyHDepOsJFcsXQOJU6SjO7cuUWzpo+jabPXBVLuVSUn/iyYN5nu3rmpK59BHb8zn7tx OFGiRqdEiZOqz6pC5Vp83t8aD6ttmE78r/UP9IoV1aRJU9LtWzfUdbNo+V5yxCtQY7xj1vSxfC0O pUw8Q482J/F2uYrVqc8f46wVl31CQAgIASEgBISAmwkEWfnEbCPkMs9swg40T77CVKCQSSEbM7y3 Wj6ds3g7xYgek2fVnlOTBpVo1PDfafL01XSaZzyheP7EdqItWnVR7Rzn2b5Xr16qbUf1VSH+c5yd hKp/X58mTlvJCqwHdWhbjxbOm0qNfmnPit4Qyp6rAPXs0oJGjp1DKVKm1arZfO3fpx07HJkHAHjI yiNsPl0VjK1mnUbUrmM/NbNbr3YJGty/CxUuWppWrjtCEby82BmmOo93sq58lilfnbr1GqGYob+l i2eoOnCIysDKrSZQrCdOW6GUNcweN2pQUX0G7rS5Dcr4nf3ctPPAa8cug6hH1xbUuH4FdjSqQo2b tqekyVLpRYYP6UHvWImfs3CbUq7fvn1D82ZPVMed5aU1doVnx/8aN5jatvudav/QVO1esmg6DRnQ lRXQmoFmobV68ioEhIAQEAJCQAi4j4C5puVCu8MGdaM+PdqoGb0svHQ5atx85Sn+/sN72rFjA1Wo VEtXouDsky9/UV6WP0EIf4Ml1H/ZWalSldp6j1gSx2yiM/W1Sil4CR1KJmwFw7PnfbHi5eklK7oP 7ptmYrVyzr7e41nEu3fN/3/g8wmKYGy/de5PHjyrGylSZMrJinBU5jBw2BTyihhRjbdAwRJq2VkL BVSiZEWdGfrMmi2v6vrO7ZtmQ2j9v576LGEmnknGDCiW8d0pro7flc/NOM4ChUrQtFlrqBCbZWxY u4zqfl+Mpv49UhV55/+ODvJMMDhoZgVg+TM7kEGc5aUK8x+YTMBMoWbdJtouKl+hBnnyg8DhA7v0 fbIhBISAEBACQkAIhByBIM98rt54nOB8hOXzRfOn0tZNq6h02e/o7u0bPNP3jqZPGcOzm3/pI4cN 40cu/+bNa146vUbe3gnUMqpeIGDDmfqePJsK8fTyDKhleokeI5baeB0wg2p20Ik3YyYuCuTtXq9W CSdqBi5iObbIUaKxkhyePCN8GjMUIchbto/FEjRsSufzrN4hVoSePHlIfm/fquMfP3xQr9of2EUa Be28efPKuCvY266O/9GjBw4/d+1zsxwc7HAHsVKOmck+PVrTxPFDKE26bygJL7PjmsmaPY9lFfXe WV5a5ds3r9Hz58+odJEM2i71iuv1DduViggBISAEhIAQEAIhTyDIyieGBiWofac/6Ag7rCCkD5RP TTGq91Nzqsj2m0aJFCmSmtnDEjlsGq2JM/Wt1TPuQ/zRkBCt3Q8cWiokpG2L2vTi2RNlNpAseRqe Fb1HXX/7NEtnr09tbPbKhOQxd3xucLAaPHI6fVcuJ+3bvYXq/PiLGjLsda2Jq7w8I3pR3Hjx6W82 /bCU+PwwJCIEhIAQEAJCQAiEPIFgKZ8YHpa7q9aoTyOG9GQP4p3KczhGjJjKgSVx4mRWzyBxkhTs ob5OLXHDE14TLMl7+yQiR/W18o5ePVjJhbxkT253SOwA28/7HLxdEzjZvODZtOAKnIhgltClx2Cq WNlkjnDl8vngNhtq9YPyuWGpHiYTRokQoGjGiBWHEiVJrpbET588QjVqNtSL4TrxZecrV3klS5Za Le3jwSdhgsR6e7Lx9RHANXTy+EHKmDGLWnX4+gi4/4yvXb1IUaNGo/jeCd3fuLT4WRNAxJKrvLKV kR09oTO4U27euMI+Jn6Uhp2bbYkzZWzVlf0hQyDINp/G4VRiT+Uo/KWzZOE0tbtKtR84M9Aqghf1 w4e+9Ixn83Zzpp0Fc/9WxxHMPQIvP/fq1lI5H/1z5jj16tGKxv/Z36n6xr7tbSdMlFQdXr50FkGR wwUYHEnAinKChIkJ3uBw9IHTVSt2GvLjZVvYsAZHYsaOw0wiKKX80aP7BCejXt1bBqfJUK/r6HO3 HNDaVQupfp2S7NE/S50vHl66dWyqrqWy5aopE4UyPJuuXUv4cVuzagHV/I7tZ6PHcJlXtRoNKDo/ GP3epTmdPXtChXBCmzOmjaHr1y5ZDk/ehwECr9iGe9WKeWze05ejQ4xS14nlsGDKs3b1QlUGn+WF C2csiwR6r2W/2r9vR6Bjxh241yeMHWjcFWa2w9rYOrb7iUaP6BNm+MhAwg6BbVtWUyN2Kr1z67rb B/Unx4ruzfqDPXGmjL36csz9BMynnZxoH2GRsMRrXOaFI02RYmVo2+Z1BG/kZi06qziV8CzGjCgk VuzY+uwVZkT7DBhHIwZ3o8bsqQ1JlyET/VC/hdp2VB+FMHvlYTFrpi3PYowQBLwvVqIcrVo+X/3v 2KW/mSe1KsR/rJ2Tfgz9BLSH1y49hlLf39sqD/OYsWJTk2YdaM+uzSqUk1kdK2PTxqWVQ+gnCPbD Katt+17KG7tCqaycXjImRwP4lXx9x+gmClp97VVvh/uyZcaglcErxh8hfOCP3JKl5XtVlzkE6tcw fpRx5nNDOU0KFCpJyK40jMNXwe4SgtBbA4ZM4tf06n07NuuAE9mf/KP2/v17lc61ao0fKTbPjLrK CzFph4yYxt7tnanhD+VU+7iO06b/hkpxrFGRsEUADwTNm1RT3zWJ+Dvj9s3ryh64Y9cB+ncJyrRs WkM9SCDWru+9ezSJbYZ/43sdDxvBFcvsX85mTQtuv87UtxybM3WkjBAQAkIgLBAIxzN2ZlN2N+++ oLu+tp0vkFITQeE1Gz/tJLD/HWengTeyJtiHJx0oWT68zGltuh35xz1ZsYkXP7DNnb36WLKFM4pl OkzMgiDmp1GQhcnf308t6Rv3a9u2zgnHsTwHBcW4PIzy99grHucEhc6yjLWxIbj8e/betuQGZd3I DEHafe/f4fiXyVXbyPhjrGPt/OAVDsXQOEbt3IyvKAeFXVOmtWOW47V8j3LOjh9l7X1uOG4pYODL 1wFCWsUMcBqzVSZhwqQqWoB2PCi8UBczag84l3x8TumJh6evSRL6mBzd7N3nYYHH+fOn1dI4zHrg qAcHs/q1S6qhrVh7WL1i1WQPr6r8yIku4LR36+Y1atqwslqJWL/1tM3TQIi4H2oWp4FD/zbLAmZZ Adcy0gdr99bGDctV+LYFS3eSM+HbLNtz53vLsbmz7aC0VbNqARXv+I9BfwWleqjWyZXFhw6f9A3V Pr/mzrBi1ff3/9ESzoyYJGkKt6LAjDviVM9esNVmu86UsVlZDriFQLqUsShWzE/O0oGnwRx0AwXS qAxpxbHfqERhP/Y5utDs2d7Zq69+DKz4oVgqnhgHZrzsia1zQh2jd7rWBsonCljSt1bG2tig8HlY eKmjriUzhGFCMHVNLFlbOz9LBVyra/lqq5zleC3fox1nx4+y9j43HLcUMHCUecpWmaDwQv9QOL82 pdOSe1h/j6QDxsQDiBmclqMgHOFsappgdcOY0hffN4iOsG3LWsJDp6N7H+1AEd28cQWvzsTlFZxy KiOb1r4x+5ezWdNczYRmK0ubNoadHLrun9PH1HcF0uUmS55aHTKOTSuL7F17ObkGHlK9fRLyvRhe XeelOFMaQro5myHNmSxgyIR2gu1m8RAuKwfaJyCvIADTMWTge/zoIWcvtB0xBisXh9lhGeER8RtQ tFhZ3Qbb2ftII45JIJhy3WFFFNkSCxUpY3XCSyvvSjY+rY68uo+Ay8qn+7qWloSAEBACzhNAsorz Z0/x7FrgTFjGVl6yAyDCj0Vn0xVHsnrlfE5ne4CSs0KH9K3TOMbs8D9n66l+jdm/nM2a5momNFtZ 2jD2fr1+pV2sfCJhxrOnT2jl8rm0dNUBdVrGsWHHimVzaOjArpSN0/o+e/GULpw7Q7FZoU6RKi0r h1XYwdO5DGnOZAEbNri7CrGXPEUqdrh8TnM5RNzrV7ZXzNSA5c9XQQD+Fb+2qquuB58ECZWttpbZ 0Ahg/pxJNO7PARx20YcfEuOxL8U0+vuvoTR05AxKnSYDOXsfoU04NP38Y1mVqMbT00vFHy9Trir1 GzjB2KW+7Wo2Pr2ibLiNgFscjtw2GmlICAgBIWAggB8yKEOjR/Smn+qW5lBZPtSds4DZEpjxnDhx mPLmL6ovldsqi/2XeaZwyozVNH3Oepq9aCuF4xWKCWMGWK2ChBZt2/dWx5A1bTEvISIdcHAEmcTS 8QzvivVHaOGKvZwlroTK0oZZHJMj1WL6pUUnGjxsKv01eRlNnrHGZneT/xpGlb+rQ2MnLaZZ8zZT 2QrVydPTU9UzVtIypCFr2NgJC+i+712VIQ1ltCxgbX7tQROnrlBLmZ26DeQEDUtp377tqpnz508p xbPeTy1p4bI9tGrjMcrMyS6QDc7CikuVlz9fFwE4DiM29ZzF22juou3094xV6sEOFP7lfxBcZ4gR XrlqXVrCD1O4rmfO3aBM90YM6a7KuPIHaZdz5iqo2lq4bDfVrfeLSmWNmXlrYszGN2rsXFq+7hBF jx5LZWG0Vl72uZ+AKJ/uZyotCgEh4CYCiEawZdNqZdf58MEDtj1+ryJX2Gp+KDuTeXlFpDbteulF YOsMRU77D1tJTZq37qo7t8EECFnWjh87oGyctTIh+WovS5sXm+lEjx6dZz43KntXjCNOQLg3yzHh HO/z0qW2JI/j2XPkVftgU20UexnSnMkCtoUjmSArWMMmv6pmYabT7fcRbKduii5i7Eu2vy4C8A3Y zw8pJUpXpgQcNhGSMWNWatriNzMQq3gG38PDk1q37abvh8lMqbJVeRl+r7pX9QNObOA+QiprmHxB 6jc0eb/v3rkpUG34NDjKwhiokuxwOwFZdnc7UmlQCAgBdxGAjSP+Q+5zTN2uHZtQt06/0OSZq9WP mrGfCeMGsb3jVur9xxgyxhj+4fuiPPNyTS+KWLpZspqyZlnaVCfhGMTIxvaEbdasOUHqjbhpwzKT mDFLG+ysO3YdzEvpXahGpbxUtER5+qV5R6uOk7DnTpsuI63jFLL5ChRXy5hr2P4tLcc+tLQrtzxn Y4Y0Z7KA3ePZ5bisBCNCh1EQKs4YBcV4TLa/DgL3799V90+KFCa7ZO2ssRQO4Tg56hVZDuN7e+v2 nWon/0keUO+2iyGZLO+juHG9VcSYRxzq0VLu3nachdFWNj7LtuR90AmI8hl0dlJTCAiBUCSARAbN WnWhNs1r085t682UT8QYnj55NLXimZRyFWqYjWrU2Hn06vWnRBNJk6ZS3rFmhQLeILoEJFpACt+A 3S69aApYcDKhaW0ga1y+gsVpxZJZBBu5A/t20JxF21SmOOOgMJsLpRKzn3VqFFWHELasd/9xxmI2 t7X+nMkCFj58OBX2zGZjcuCrJeARMPP4LiB0ni0QiPONhzxLefvGNEsfM2YsFbYRx4N6H719+86q U6n28GUvC6PluOS9+wmI8ul+ptKiEBACIURAy1amZRtDN5jtQ6xYLLU1+LlNoJ7tRdy4fOmsPrOK iqfYXhSJJCxnC7VGncmapo3NXZnQMMNY76dWKjtMy6bf0+kTR5RtqDYmvF5l29jTp47RvMXbVYY4 noKkeGwf66o4kwUMs8PrHi6hmzev6pE5HnIqYHdkenN1vFI+bBGIx9mtEEXkDEdnMAqiJxglKTv4 wZwGiV+SJkulHzp6ZC9ft94qS9a7AOXUmfvo6dPHZtEtYOvp5/eGUqRMo7etbQQlG59WV17dR0CU T/exlJaEgBBwIwE4GSEea5ny1SlhomR0iTMXjeNMR7B7LF6iguoJ4Y/69+1A6TNmJnjUIuuYJojD 6SgW54xpY9UMS1meLd3NtpWHDu6mps07aE0EejVmTcNyNRx6jD+eqGDMhJbxm2wcT/aeyr7kaiY0 lUVt2zpCRjic8/6921U832TJP/1YawOMz2GVvL0T8KxwLUrOP7hQnmPGjE3Zc+aniuwUZRnbV6tn +YrA/PM5Ex2ygLXv/AdHAUijzB12cNicYsXLq3A4aG8azzL379Oe7ez60nP2wh86qKtbMr1Zjkfe f14EYHNZlBPObNqwQmWuy5m7kHJmW7FsnjoRzeGoZq2G7LQ2jXrwddbut74Ul+Mtw954145NbK9t Skzjyn2EsGotmlajlm27q+t+cP9OKtJD+Yo1rQJENr6F86ZShm+yUkm2T4VZwKmThzmRxTWq/UNT q3Vkp3sJBFn5xDLPWg4ci+lzy2UuDBGpEvHliWWsXLkLUq48hfWRn+Jc3RfYY9KaILh6frZZ0gRe cYcP7uIwI485nl92ylugmEMvVjgWIJ0X4vfF4C9gxBlLly6T1qTZKzKWbN28mspVqqkbSBsLONM/ nroQ0+zG9SsUKXJk5bQAI2sRISAEgk4A9+2oYb9zCCHTDxda+ubbbLyUPF7PH46ZSmTHOnvmBHXu 0NissyrV6lJ3doSxJvBqh3T/fbgK7zJ7xgTlRFO5ah2VWUyrY5nty5msaVD0gpMJDX0jaURMzuK1 Y9tamskKMgRZ4jp06qfHTjaODU4/mHGNGi268vrF9+4V/v4b0Pc3/q49Q7917q/aRDuBMpVxXbQF cSYLWEJOM9yr358qe12DOmXUj3yDRq3p6OG9gdpWjcqfr4oArjWk1R7cv4uKfpAlay7qxxkN27et r2clhD31sFHTaNAfnahZ42qKT5y48aj1/3pwwogW6r0r91HR4uU4+1106ty+kUo+A+e3wSOmqpBr aMx4r+C9q9n4UEfEvQRcznCE7qHU/dGnHQc+Ps52V1loOodI0ATebp3bN1RP6Rm+yUJvOP7WpYvn +GmiCbVnbzTIEI5Fh6UyS3n96iXH18tGU2etU4eWLp7BxvbdOIhxIvXFih+YQuyNOmDY5ECZjbS2 rKXb+/DBP1C6PXi8zZw6hsO4jFMxwoaOnKYCTGvt4NWZ/jdvXMlP/V2UIXVKTgmJc4Dn6TwOMSEi BMIigc8lw5HG7tmzJ7yk9lAFM7eWZEEr5+qrlj0M31m3eQkZwdI1ezCtLWvZvnDMUdY0lMEDuquZ 0FAPD8/G84SjlR9nlcOsq0oAgUIsxrEhHNVUno1cs/G4/oOLMm1b1laZvLTvI8u2UQbfV9YypDmT BexuQKY3zHhZZnpD22FVJMNRyH8yiMuLkEuYgYdo95tlzwgmjzidmne85XFH95HxusNE0Ft+8LJs y3ivGNtH246yMBrLy3bQCQQ7w9FWzsXdt2dbKl6ygkqzaTmUZYumq6nzwcOnULGApbHBHP5kwdzJ VKXqD5SGvS87dR2o/hvrIj5fzSr59RlS2IIMGdCVavD0fMcuprh769cuoV7dW9M69uL8rno9Y3V9 +xUrf1Vr1AuUbm/iuCFmuZ5/4RR8T548Iky/z5/zt15f23Cmf4SBwZJfAZ6p7TNwvP7DgJtBRAgI AfcQwI+X9gPmnhZNrWiKJmZYjCGKjH1Yy/aF485kToJC5momNLRtVDzxHjZq1sQ4NijQePDdvnUN lSr9nUpBi9SjmP3Mm7+YXt2ybRywlfnMmSxgmAXVxFo2OO2YvH59BCyjIWj3myUJZC7Df1vi6D4y XnexeLXAmhjvFeNxtG3PJtxYVrbdS8DlOJ8xYsSkMX8t5GWXMfyEHS3QaGCXlDRZCl3xRIGfGpvi wW3ZtDJQeW3H3JkT+Ok7AtWqa1o6W7l8Hi/pR2Dv1e5aEbW8nzhJMtrEs422BMtiTTkcCfI8Q7R0 e1A0MVuhSVm2I5u/ZKeaSdX2GV+d6X8eZ/WIyDEFe/YdrSueaMN4MxjblG0hIASEQEgQqFWnMRUu UpozIrWjEoXTUsnC6VWO+2w58vNS/R8h0aW0KQSEgBAIMgGXbT5zsQGxPXn+/GkgT1FMgceOHYew JG5NkHN4w7qlvOxdRvfQPMtP7fBUg1G/UVKlSq+W/Y37HG1bS7fnyKjYmf6PHd3HM7WFAp2vo/HI cSEgBISAOwnge3LY6JnKQevevTsqUxNindqabXJn39KWEBACQsBVAi7PfDrqICl7Yl6/dkWF4dDK wnYoAnuFvnr5KdaedgyvSxfPVHmL69Zrpu9++vQRaQGX9Z28ETNWbM7f+ty4y+62q+n2tMac6R+B q58/f0JtWtSiciUyUflSmal5k2qE5S4RISAEhEBoE8BSOfJip0qVThTP0IYv/QkBIeA0AZdnPh21 XJ/j0e3ZuZl+aViFsmTPTQgae/7sSXrK4TjSp88cqDpslaB8Zs6Sg52NsuvHUQ/em5aCkAiv+RgM hf0MaeMQf88rYkTL4mQt3V6gQlZ2OOofs7UfeeyX2ZkKdqM/sIfek8cPaOqkkdSBvfoWrtgTKAOI lW5klxAQAkJACAgBISAEvioCblc+EVdv1vxNypsdKbRipUxHP7PNZ89uLTlUSGBj4C0bV9DtWzeo WcvOZuARMgQG9JYCj7lYPPuJME+wb9IEhv3L1hzU3qpXW+n2zArZeOOo/wgRTOnCypSvZjb2aDzz 0LHdz7R/zzZCdhIRISAEhIAQEAJCQAgIgU8E3K58oun4nOXAmGnkMYdJecBp3zJyQFdLQco4ZBQp WaaK2SEsud+5fd1sH94g7Ag82kqWrkJp03+K3Wnp/GQv3V6gRq3scNQ/ZlmhaCL+qFGSJE2p3r54 8dS4W7aFgBAQAkJACAgBISAEmIDbbT6tUZ05bYwKH1KqbFWzw0iBdYZjhX5X7Uczb3EUysGZOTAj anRSQtyws2dPc9D4kqo9LONr/5MGKH2o6yjdHso4Ekf9o37yFKk4pd0Rs6bO/mOy94RjlIgQEAJC QAgIASEgBISAOQGXlc9n7M1+/Oh+9f/165f0hu0u1ftjB5Qd5mnOarSDU8I9uH+XFcUTNHJoT5o3 exKHW2qrZiyN3c+ZOV7lga1R+2fjbrVdvnItdQxxPZERCblhu3dqyuGXPDiOZ/1A5bUd1tLtIeUe /iMupybnz59W40bAfAiO4TwQNBniTP8VOCsSnKvGjOpHt2/foN27NtHE8UNUoPxsOfKpduSPEBAC QkAICAEhIASEwCcCLmc4wnL2EM46ZE2WrztMpzndHWwx/fzeqCLITlS/YSuqWbuRWRWk3/qufC6q VKUWde053OyY9ubokb3Uv3c7usUzoOE4GGzK1OmoB6fLy8Q5nG3J9CmjacLYQVYPG9PtfVc+JyEk iaWUq1id+vwxTu12pv9hg7tzDtvZKsWfF8f8zJuvCHX9fRjFjett2bS8FwJhgsDnluEoTECTQXxR BCTD0Rf1ccrJfAYELDMcuax8OnOO7/z86M6dG+xgFDfQbKexvrVUb8bj2jaCw0fw8vzPvMcd9Q8n KNiiJmCnJwkwr31q8hpWCYjyGVY/GRlXaBEQ5TO0SEs/QsBEwFL5DBGHIzjjwOvdkVhL9WatjjOp 7KzVc9c+R/0jkHPSZKnc1Z20IwSEgBAQAkJACAiBL5aAyzafXywJOTEhIASEgBAQAkJACAiBECcg ymeII5YOhIAQEAJCQAgIASEgBDQConxqJORVCAgBISAEhIAQEAJCIMQJiPIZ4oilAyEgBISAEBAC QkAICAGNgCifGgl5FQJCQAgIASEgBISAEAhxAqJ8hjhi6UAICAEhIASEgBAQAkJAIxAozue///6r HZNXISAEhIAQEAJCQAgIASEQbAJIFqRJoDifL16+o1ev/bXj8ioEhMAXRiBqFE91RnKff2EfrJyO 0wQSeEele/dfOV1eCgoBIRA8ArFjRaZIET30RmTZXUchG0JACAgBISAEhIAQEAIhTUCUz5AmLO0L ASEgBISAEBACQkAI6ARE+dRRyIYQEAJCQAgIASEgBIRASBMQ5TOkCUv7QkAICAEhIASEgBAQAjoB UT51FLIhBISAEBACQkAICAEhENIERPkMacLSvhAQAkJACAgBISAEhIBOIFCoJf2IjY07t2/Rpk3r 1FHEbIoeIyYVKlyM4seLb6NG2N998uRxOnhgLzVu0oKMcagw8pUrl1LkyFGodOlyYf9EbIxw/brV 5Ot7Vx319IxIGTJkpBw5c9soLbuFgBAQAkJACAgBIRByBAIFmX/+ws9unM9BA/vQn6OHUaJEiQkB 6R8/fkQfPnygtr/+Rr917B5yIw1Cy5cvX6K5c6bTr//rRDFixLDZwoD+vWjsmBF07cZj8vIyxUDU Cpcsno/isWK9YNEqbddn95oiWVylQEeNGpXevHlDT548pixZs9G06QsoYcJEwTofZxkHqxOp7FYC EufTrTilsc+QgMT5/Aw/NBnyZ00g2HE+P378qADs3X+Kjhw7T4ePnqM8efPTiOGD6Pjxo2EKzqlT x2nC+NF03/demBpXaA/m/fv3VLPWD+qzOnP2Oo3/axqdO/sPde3SLthDEcbBRigNCAEhIASEgBD4 qgi4vOxuSSdu3HjUrHlb2rtnFx0/dpiyZcuhivj5vaN161bS+XP/UOIkyXjZujz5+PiYVT929DDt 3r2D3r3zo5Ily1K27Dn1447q79q5XZXNm68grV27gi5eOEe5cuel4sVLq/17eDx7uG3IqlXLKL63 D+XjsmnSpFX7gvLn2bOntHjRPKpcpQZ5e3vrTaxYsYTfJ6D8+QuqfdrYcufJT6t42f7y5QtUpGhJ KlCgEH1g5X3Jovl09eolypu3ABUrXkpvBxsY94H9u5nJO0qXPiNV4b4iRDBlBXjx4iUtWjibFcl6 dPfOLVq/fjVhNrNS5eqB2Jo1avGmatXvaeaMKXTo4H79iL1+UejevbuE84Qin+nbLGpcB9hUwd2M 9QHJhhAQAkJACAgBIfBFEgi28gkq9+7dUXCgZEJgF1qvXg16+uQJZcyYiaZNnURDB/fjZd75uq1h v7496K8Jf7KClYHChwuvZk6HjxhPderWc6r+lCkTVPv+7/3p1q0bFDVKVBo5YjD9r10n6tS5J61c sZg2b1qvxjN/3gzy8IhAEfh/cJTPSxfPU88enSh5ilRUqlRZ1Tb+DBnUjzJnyaorn9rY/Pze0v37 vqocTBUGDR5Jy5YtJrQTPXp0Gj1qKHXr3odat2mvyjRp9CPt3LmVMmXKQuE9PNSs7exZ02jpMpON 7e3bN6hH9450/fo1mjN7GiVLnoJu3bxB48eNorXrd7qkgEaPFo08PU0mBo76PX/uLFWrWpaSJUtG SZIkpxXLF9OL58/on39Ou52xAiF/hIAQEAJCQAgIgS+WQJCVT8w2Qs6dPUOzZk6hwux0pClkvXt3 o7dv3tK2HQcpZsxY9Pz5c6pcsTj1+r0zrVqzlY4eOaQUzzZtO1CXrr1UO/v376WXL1+obUf1VSH+ c/DgPqrfoBGtWLmZlcvwVO/HGjR1ykRq174rDR4ymvIXKEwtm/9Mc+YupzRp02nVbL62b9eCFeFP ie9REMojbD5dFYzt50bNqO8fQ+idH8/ssu1ol87tqHSZ8rz8fV7ZllavVp4m/z1eVz6rVa9Jw0eO U8zQ38wZk1UdOERlyZJNHwKUv+UrN9G3PAOJ2eOKFYrzZzDZaZvbK1cuK3aYNYY46nc2K7qYYV23 YZdyyPL3f0+vX7+knxo2dZmxfhKyIQSEgBAQAkJACHyVBIKsfHbv2p5evHhBsCeEQjWVZzXhKf7+ /QfauGGNcvKB4gmBs0/RYqVo+rRJBMVl9erlylmpdp36OvR8+QqobWfqe3qaho1ZTCiZmpSvUIW2 bd2kZmKTJjXNwmrHnHnFLGK48ObRp97zzGpQBGPrP2CYqho5cmQqULAwPXz8kCZPmcszjqbxlyxZ hgbs38McX/JMaDSqWKmqWVd5eFkecvPGNTPls2fPP5TiiWPZc+SipMmS05Url/DWpuzds5N+69Ca Hjy4z579+7i/GDRgwHBV3lG/ceLEVfU2blhLZctVVOPXPlubHcoBISAEhIAQEAJCQAhYIRBk5fPY icsE56N+fbvzsvpEWs12ld99V4NusKIEe8WxY4bTxL/G6F36+79T5TFjdu3qFUqQICGlTJlKP65t OFNfU3w8Pb20auo1VsyY6vXFi+dm+519s3DxGqve7s7WN5azHFu0aNEpQngPXfFEWcwmQt76vVHK J2xKJ00cS7t2bqOHDx/S27dv1HHYiRolYqSIxrcULWo0evXqldk+yzevX79SSnn8+D7UrkMXql+/ EXvAR1bFHPXbrHkb2r9vN/3csA6bBGSm5mzjW6NmHcsu5L0QEAJCQAgIASEgBBwSCLLyiZYjsRL0 R/+hymloxLABSvmMHCmS6rR5i7ZUyzCziZ2RI0VWS8qwZ/Tg/9bEmfrW6hn3hbeYvTQeC852OLZN hSC0VEhInVpV6MnTJ9SuXRe2TU2jnHyaNvk0O2yvT8v4pJZlS7HDV99+gy13q/eO+o0SJYoKNQXT iAnjRlKbNk3p1u2bPLvd0Wp7slMICAEhIASEgBAQArYImK8x2yplZz+Unvr1f6aLFy/Qzh1bKSHH /4zJM5A3b1yn5LwcbPyveYinSJGS7t69w45CN81axpK8M/XNKtl54xGghD5n5xh3SNz4Jg/3O6x4 aQLnKswcBleuXbtGJ04co1at/ke16/xIOXPlZQU0fXCbdVjflX5hGjFj1iKCrejGjWtV2+5m7HDA UkAIuJkAbKDhPCciBIRAyBB4yStzx48dUeZ27u7BmfvXmTLuHpe0Z59AsJVPNF+7dn2Kxt7T06f9 rXr74ceGKrwRnGl8fX1VUPNN7Hn+96Rx6nj9n5ooT+tWLX5WzkeID9q6VRMa0P93p+qrQk78SZos hSo1a9ZUDvl0lu0iLztRy3aRJEmSUuLESWjK5L+Uo8+6tauoRo3yKlQUx9sPlsSJE4dDKkUgtHn/ /n2Ck1Grlo2C1aYzlZ3pF5EJ8PkhQP2F8+fYw/46pWSPf4i7GTszZinz9RF48fwFzZs7i818etCo kUPU/WFJ4fXr17RwwVxVZsyfw+nMmVOWRay+79unG7Xh7x97MmXyBBo4oLe9Ip/lsS/1vD7LD+ML HvSaVcupQvliHKnlutvP0pn715kybh+YNGiXgMvKJ5bLMduJ/5pEjxGdypStSDt2bFEKSqfOv1M9 tikcwuGVsmdNQ5kyJqf/tW1GT3lJGYLZ0LHjJquQQZUqlqAK5YqqeKA1vjfZETqqjzY82H4SyppR IkQwhQ7CMQhijpYrV4kWzJ9NxYvloR3bNxuL69vWzkk7iGPaMj5m+YYM+5O9958pD/PfOrSiJk1a Ui6epdRicaKetbEZ29Ha1saPduGU9Xuv/nT48AHKliU11a5Zmb6vWZdix47N7Zk+Ju28EDbKKGhH O2bcr23juNaXtk97daZf1G3+SwNKndKbihXNzQp4Uvq990DVhLOMtf7kVQi4SuDSpYtUsEBWGjSw t0qDO5XDrJUvW4RmTDc97KI9lMmfLzN179aekE521MjBqgwicbhD1qxZqWL2am1dvnxJKbmI5PE5 iK3xWp7X53AuMkYhIAQ+fwIup9dESk0EgIe9p1Gw/+3bt7oTC45hH550oJhhxtCosGp1b/OyNRQz OCBZir368IqHw5NlOkzMfsBG0SiPHj1U4Y4QFRrmAABAAElEQVSwpG9NbJ0TysIUAOM2Kpcof+vW TUrE5wTF0LKMtbHBacj/nX8gbphN1Bx/0B/Y3uEA8ojhibbfvvUzq2Pt/N5xu1CQjWNEW5qgjYgR vazy18o46hdtYMYzXvz4FCtWbK2a/uqIsV5QNv5zAp9bes3Tp08qpbN+A6yYRFBmLqVK5FccDx05 q16xerJ50zpOePGrct6DOUmVSsX5O4jo1Jmrdpk3/Km2MhPasu1T0gXLCrjnP3z4qN9jyzncGcK4 7dx1xKkwbpbthfZ7W+O1PK/QHtd/1Z+k1wxd8gvmz6F2/2tOyIyYIkUKt3buzP3rTBm3DkoaC0TA Mr2m+RRaoOKBd0ARs1Q8UQr7jUqUts/RhQal1JagTVv1TYqWaYbTWN9S8cQxZGGyJ7bOCXW0sEjG +ihvDOVkWcba2KBIelgo7GjTkhmURGMUAEvW1s7PUgE3jhXblm1YHsd7R/2iDXuxUh0xttan7BMC zhBAPFv81wTRLr7hqAt7OXyYJpiB17KrYR++N/LkKcDZz1YSHoycuT7xELlw4RwV2ix7jtxUhkPI 4V6H7Nm9U614VKhYRWUhczaz166d21V9W5nY1EH+4yijG8rBLnXrlo0cY/cVJUyYiMPCeagVkypV qqtm9uyxnh0N+22N13heW7ZupJccPg9RS4yC+g8e+BIyo0Ewjp0ckQPjyJUzD2dvK2EsLttCQJmO bVi/ih48fEAlSpSxSQQrFnt2b1fOtWlSp6MyvFKJsIMQZzMKao3bu3+1MsZXZ+45Y3nZdi8Bl5VP 93YvrQkBISAEXCOApe5TbBP97bdZ7VZ89vypCmcWM2bgmXrLii9fvaRyZQqpRBdeXhEJGcmqVvue xk+YpopOnjxezY5C+XQle5qW7cxWJjY07kxGuDlzZlC3Lu0oT978KrMb7FmhUKdJm55T3VYne1nK 7I3XeF67WVGGDWi+fIXMsqV1aN+S0nOqXyif48aOpKFD/mBFPyfHJ35Ow4b0p+o1aiszKkum8v7r JAD/ih/qVlXh/xImSkSj2UY7Bz/MWcok9gEZ2L8X+fCqJxK5TOGQjUOG/kEzZi6kDBm+UZkAncko iHYd3b+WfTtzz1nWkffuJWAyJnRvm9KaEBACQsCtBPCDBsWnD2dPK12qAHn7+HA2sPE2+4A5z+FD B6ho0ZL6UrnNwnwA0TkKFipK+w+epl17jtIvzVrT8mWLORNY4KV4JLbo1cdk84zsaXv3n1RpgW21 j2xnmLk9cvQC7dl3goqXKK0ysWGmBmLM6DZn3jI6ePgfNm2JpTLCaW0OH9qf+6hPizgW8aYte6l6 9VrKaXPZclMKYWQpgwnCshUbaMnStdSPM6shNi8cF50db81aP6ikIcuWLdS6VQ6hNzidL+zx4Ww4 eFBf6t6jL2dY20gwUxg4aAQtXbKAtm+zbk+vNyQbXw2B/v17qnCEW/n62Lb9IK1cvYWuXL2kzv/f f00xq3Et/cHOg3XqNqD9B07Ras58uHHjHvJj070e3X9zmZUr9y8ad+aec3kQUsElAqJ8uoRLCgsB IfBfELh48RxH0FhKmzauo4ecpesD23xfOG+y97Q2ns6d2rIpSSTq2XuAfhi20bCZ1v7D3lETZCRD HFxtmb1lq3bq0KaAkGJauaC8apnYYI6D9pGJDU6L9+7d0TPCQfHTkmdoGeEQeg0KKsZ9795dSpU6 rd59Xg57hn2wGYcgS5lWH++N2dHw3hn55ptvKWPGTCphiFZ+CSuWmGEtV64yLV48T80kN2naUjvM s5512e7ei3bt2q7vk42vlwB8G3Zs30qVKldTPhEgkTVr9kCpn+fNm6kenrp176vDgqlM1Wo12Zxm l7pH9QNObLhy/2pZFO3dc050KUWCSUCW3YMJUKoLASEQ8gTwY4b/kLt3bnOUiXr0S9P6tIpnTPDj ZpRBA/twmt3NNGbs3yqyhnasWJFcdO3aFe0tzwiOovoNGqv3lhnJEJMYypyv7z29fFA3LNs2ZmLz 9/d3mBEO44BSuGTRPCpRvDTFjRePQ0rNUfs0m3FHWcqcHXsVtvdElBLMHMMeH8p3CU4DDLvya9eu sh3eM8qYPqlZc8ho5yjDmlkFefPFErjH8btxTUMZNIqXp8lBWUvUgvsQqxeafadWNnXqNGrTeJ9q x+y9Wt5j9u5fV7Io2utTjgWPgCifweMntYWAEAhlAoha0blzT6pT+zvasH61mfI5fdokZa/ZrXsf ZYtoHNrc+SvYTvGZvitlKtMPnb7DYuPdOz926DGl7LU45Ja3iFDhTEY3zNBG4lS4+GEvygo0JG26 DDRu/KcwUo6ylDk74Fo8AwubziWL56tkEojqUat2PVU9Is9wxudEGytZ4beUhAkSWe6S918hgfAB Dnp+/EBiTxAW0d9KmdcBM/mxY8ehtwHbQc0oaOv+deaeszd2OeYeAqJ8uoejtCIEhEAoEoCzC8To xb5k0Xy2F+tILTlLWOs27QONBst6tuTx40dmXvGw9cSSdtq06axWQfQKSHCzp1lmdLPW2Xk2Lzh2 9LCyn4vJtqCYPfLhWSNNtCxlmMlFdjQIbGSN4ux4MZ7cefLTmtXLOeTbbRXVo2DBwqopLPsvW7aI IniYQucZ25dtIQACCTgKQzSOWX3s6CEzIOfOnTF7jxlOXGNI/JIqVWr92L69u8jb20dFc3jHM6gQ ZzIKunL/OnPP6QOSjRAjIDafIYZWGhYCQsAdBOBk1KF9KxXu6Do7BiGIfL9+PdlDNh5VqPid6gLh gDpw0ofMmbNSTg7/g0xh2v9LnPrXkSAcU/Wq5WjDhrXKyQg2o1Bsa9T8wWpVd2b2cpQRDmGVEAe5 Vq1KnPWsMbNoQW1bN6W5c2YSbOycyVLmynirs/PSqVMnlHIAW1JNGvzUWKVObtHsJ5UKGCkTwRbZ pBAyR0QIwKa5XJkK6t5DZsGrV69Q3z7dac7cGQqO5nDU8OdflJKKa2n//r2q3DB2qoNNd/MWbVVZ VzIKunr/Orrn5JMMeQJBnvnEUhACx8IWCKE2LGX3rh106NB+FQsuXToO08GGxMZ4mEiXt5qffC5d Os92HzGUXVGWLNksm9Hfb+SL8vKlCypmWPoMGfX99jaQ1WP1qmVUkzMFISC8pSAX/VGeUfDze0sF CxalQoWLWhZR7/HDhic5PF2lTpNOeZpqtlZIH7p583q6cvmielozGjFbbUx2CgEh4BKB4sVLUa9e XTi95ky9XlaO6zmOs6RBMYMc5u8a2B7CSadxI3OFEV7iI+x4xiM7WFmOLwhHn8Y/11XJKxDHd8q0 eRQtalTVvmXWMmNmL2RQ6z9gmNkMjqrEfyzrYb9lJjZkdMPYYWv5e8/OqiqWHRv+3FRte/ASJULR ROPvyYKFiqjlyPPn/qGOv7XmFKInVd/Ijob6yI4GG9Ff/9eRlcJhKlEFGrE1Xmvjq1q1Fqc67q3S ItepU1+NAX+gjE+dvoC6dP5VZY/CPigbcFSqEhADFPtEvm4C/QeMULbSXTu3U4lmkAFw/Pip1KDe 93ztm1QOPExN52upc8e2/NBXVgHDNd6jZz9d+cRsPTIK/tqmmcooiGx/7Tt0pS2bN5hFsAjK/evo nvu6P8HQOXuXMxxhWOf4i6/d/1rQCc4qkiVLVlq/cbfZaFs0b0grli9RBvG4oJAyEk/eq9duU1/m eErGBYcvrmScavP69au85PWIBgwcTj81NH3hGhvEU3ilCsWVITOW02DPZU/gzYYv3vHjRipD+GnT 5/OPS0W9CmYLGjWso8KDQOF9xcGSz539hxo3aaFClGgFsezWsEEt2r17h7Kxis/ZfS5eOE89e/7B MyKm+m14BiJixIickSglL3WdYQXbi8OdbDQLFK+1J69CICwQ+NwyHGnMnjx5TI8ePlQPktaSLWjl XH2FRzm+i+CNjgdM2JpZPqxay1qGfhxl9rJVz1qmMjzQW8sIhxBTo0cNoaMnLunKMPqGnec9doja vuMg3jrMjoYyluO1NT4wga2drQQVmDzw9b3Ly/8JCemVPzeRDEch/4khHu+HD+85RXQc1Zlltj5t BHCWe/XyZaB7TjuO+wK2x7YyCgbn/rV1z2l9y6v7CFhmOHJ52R12GlAE0/IMIDwwLQVT6FA8u3Tt peLALVi0ioPHzlVhUZYtma+Kv337hv7XrhMdPnpeeavu2nOMErGt0dgxIyybU+97dOtAJUuWVaEZ rBaw2Fmlckmaz6EcMLVuTWZyTmhM7/81cYbqf+u2A9SAvV4RYBnZOzTBUxlS+y1Ztl59wSPG3rET F+k7nsXFBY+lueQpUtLuvSdo6bJ1tGbdTqUg9+ndVWtCXoWAEHATAfyIIcuWOxVPDA0rMqasZMRL 2HGt/gjiuLVMYpgNhA2ZLbFVz9o5QAFOwXapWG7EtiZQAl/yj/Pa1SuUgon9SCeKSQCjp7+WpUyz 77SmOFqO19b4wMRafW1MUDjxWXyOiqd2DvIasgSwkqApnujJ1vWEmXrLhz3jyHAvYCVCu66N9yvK Gd+7ev/auueM/ct2yBBwWfmMFSsOLVi4kv7kMCbRogV+4kVAYkjhwsXUK/5o9kZaOA4EXG7UuLm6 aHAcFx/S5T19+gRvzQRL+2fPn6V+/Yea7bf3phorhzt2HaVSpcpZLbZt2yb+kk/F8fYq68fb/moK bItleghi6K1cuZQaN23BGT8K6OVwseIL+/z5f+jmzZtUr14j/aZKwT8cJTksCVLZYXZVRAgIASEQ XAKNeEWmdOly1L5dC0qXJgFlSJeE89aXpHz5C9If/YcHt3mpLwSEgBAIdQIu23zC5sie4Die6hFr b9qMBaxgeilbJCiY39mwC7KVLg8G7UMG96Vmv7RSMefs9Ws81pTL25NnT58FyqmOJy88NV0McE7Y uWObssOqXr2O1aaePH6s9keLFtXseHpOC7aYw5RcY0NrLWaZWQF5IwSEgBBwgQDsTmfMWkRY6r59 5yaFZ293mPnYmklyoWkpKgSEgBD4Twi4rHw6GiUCE/855m82hm9DxYvm4jRxcdSM5nTO16o5B6AN hAKBo87Dhw9o7dqVVtPlDeFUbrCnbNO2o6NuXTqekkM7rFi+WHnYpUyZStXFF7unpye9DAjhgowq mOWcPm2iWqJ/8OgBecfzpnLlK1HnLr1UEF3E6dvI3rFa8Gs09P79e9Xec7ZjERECQkAIuIsAlrgz xPjGXc1JO0JACAiB/4yA25VPnEmOnLmVLRI8yR+ygwAU0nd+fmYnqaXLe/nipUqXF4M9OZEuT4v5 BceeWTOnKLtMa7ZWMBTWUsuhYQ+PCKyoepn1YetN69btlcfcd2wbmjt3fm7ntcqBDIeGbzNnUdVe vHihPPUuXjzP9qmdKXacOLR1y0Z2Yhql0sl14iDXP/z4E82eNY0uX7nEdlrJlMe7ZjMagRVZESEg BISAEBACQkAICAFzAi7bfJpXD/wOcfgqli9G/u/9afvOQ2x7eUQFnq33Y3XORrJGr4DZwvUbdrGz zjHazQ5HXjzDiXR5CJUC6d69AxUoUNjMS12vzBuwBU2Tykf/X6SQ7TBNxnrYhqH8xs176JdmbZRS mYXT801mpyiEf4gTJ54qjllQyPQZC6lmrbpsP1pWeePDu3/dulXq2JChfypnqjwclBmG1VBGO3f5 XR3z9k6gXuWPEBACQkAICAEhIASEwCcCbp/5HMqx5rD0PGPmIt0rdc7c5VS0cA4aOXKQVWUS3qLG dHkpUrAHOccJRSq3vHm+1UeLnLFzZk/n2J3LafnKTbRh0279mDXnJ/2glQ2YABizoDzg5X84GWXL lkOVhv0n5BEvt0Mp1SRhoiR0hj3gNYHTktFxCcGwEyVKZJaBRCsrr0JACAgBISAEhIAQ+NoJuF35 vH37lvJi9/KKqLNFKAQEkvd/Z0qXpR8wbBjT5SGf8sBBI3T7Sa1Yr9+7qOV8xOyMy9lNvL29tUPB fh3HYZ7gKKU5RWXm+J8QOB7Vqv0paDXMAZIlT6GOWf6BArt2zUr6noPaiwgBISAEhIAQEAJCQAgE JuCy8olwSOcC8ga/fPmCFUR/lR4Lzjl58uSj/Bz+48D+PdTr985U94cGrNBFpeXLF6l0bci5DEG6 PORErl69NiXhIPNnz5wyS5eHtqwFm0earm85fZ61Y8ZTQ2xOxMU7G5BPFnabMWPFVvHzEEPv6JFD dP++LyFLCl6XsHf65L/Hq9ik2oxnsWKlVPkRIwZyqKjkPJOZgP6aMJpz0V6iXn0Gqu5gk5qDU/nF 4SX3I0cO0sABfVSWFMQwFRECQkAICAEhIASEgBAITMDlDEfTp02ibl07BG6J9xw6clZlvOjerT0t W7pQKYAoGI2DzX5fow717TdExchEWkuky4PHuyZQBP/4Ywjl5FRctiR1Sm+202yt21XaKpcrRwa6 c+d2oMNIAzqWU/KtWLGE2nOGJs1hCcvkLVu1U7FHjZUQyLlt6yZ63mIs1cPTXZsJLVe2MJ08cVxV gY1okaLFOUPScErB8T5FhEBYJfC5ZjgKqzxlXJ8fAclw9Pl9ZjLiz5uAZYYjl5VPZ08fadvu3r1N CEeE7EWYzbQUV9PlIT0XPNqttWXZtqP3fn7v6OaNaxQnblwV39NeediChuPYej4+PoGK4RiC5yfj 9KEwLxARAmGdgCifYf0TkvGFNAFRPkOasLQvBMwJhJryad6tvBMCQiCsEBDlM6x8EjKO/4qAKJ// FXnp92slYKl8uj3U0tcKVs5bCAgBISAEhIAQEAJCwDEBUT4dM5ISQkAICAEhIASEgBAQAm4iIMqn m0BKM0JACAgBISAEhIAQEAKOCYjy6ZiRlBACQkAICAEhIASEgBBwEwFRPt0EUpoRAkJACAgBISAE hIAQcExAlE/HjKSEEBACQkAICAEhIASEgJsIBIrz+fHjv25qWpoRAkIgLBLQQu7+K7d6WPx4ZEyh QAD3gFz/oQBauhACAQRwzxljtAeKin7b9yXd9X0lwISAEPhCCST0iarOTO7zL/QDltNySCBXFh86 fNLXYTkpIASEgHsIpEsZi2LFjKQ3JsvuOgrZEAJCQAgIASEgBISAEAhpAqJ8hjRhaV8ICAEhIASE gBAQAkJAJyDKp45CNoSAEBACQkAICAEhIARCmoAonyFNWNoXAkJACAgBISAEhIAQ0AmI8qmjkA0h IASEgBAQAkJACAiBkCYgyqcThP3f+9ORw3vo9asXTpR2f5H/un/3n1Hot/j69Ss6c/oYfZT4KqEP X3oUAkJACAgBIWAg4LLyefbsCVq0YKqhiU+bly+dowVz/6b3H95/2ulga+H8KTRh7EAHpf7bwzeu XaaWTb+n/ft22BwIlJotm1bR+DED6K9xg5SyarOwiwec6d/FJlXxndvX0+qV8+nt2zeBqm/dvJqO HzsQaP/numPbltXUqH4FunPrus1T2LZ1LS1ZNN3s/9rVC22WlwNCQAgIASEgBISA6wQCxfl01MSm 9ctpzsy/qGbtRoGK7tqxgRXJQVSu4vcUM2bsQMet7di2ZQ098L1LLVp3tXb4s9j3zs+PmjWpShcv /ENp0mSkN29e07TJo6l9p35Uu26TMHsO3To3I/937+jYkX3Us89os3FOHDeY0mfMTNmy5zXb/yW/ 6dmlOXl6elGkyJH104wUKTJVqFRLf+9oAw9TceN6U8nSlR0VleNCQAgIASEgBL5KAi4rn+6mNG7S Evr48YO7mw3V9pYtmUn/nD5O4/9eTDlzFVR9Y4bY703gGcVQHZiDzj68f08JEiamtasXU+0ff6F0 6TI5qPFlH/7w4QPVqFmX2nXsF+QTXbZkFiVPnlqUzyATlIpCQAgIASHwpRMIUeXz0IGdil/WHPlo Oy9pXrtygTJnzU35CxTXuR49tJtevHxBxUtUoL27t9IrtqssXfY7/Tg2YG/56NEDKlO2qtqPmcbt 29fRFV7mT5gwCRUsUprixfNRx2CXuWb1IqpYqSbt37+Tzpw6ShUr16JUqdPTwwf3aNOGFfTw4X1K lz4TlSxThSJ4mBCgj2NH95O/vz+lSpXO7Jhq2M6f67wsHz58eMr0bQ69VMaMWfVtbQNjOcz9+L/z o/wFS3L57NohdY6u9n/p4lk6eGAHvXn9mrnmojx5i+jtObtRrkINWrF0Dv05og+N/cv+EjNsT/fu 2swzvGcocpSoPCuaTz8HnNvFi2eoavX6etf3fO/Qzm3rqBLzjxI1utr/4eNHWr54BuVgJT0lc7aU x48f0o5ta+nWzesUO05cKlS4NKVImVYv5sw1hcKPHt0nmBU8fvSQWZfQ6wd14/mLZ7R+zWKlVGJm UxNcT/Hie1P69N+qa+sVX8v37t1mprMVozLlqpGjutlz5Ff2xLauW/Tljs9aG7O8CgEhIASEgBD4 LwmEqPKJJcjnz57Se1Za7t29TZEjR6Epk0ZSo6b/o2YtO6vzXjBvMt29c1Mpn4cO7qSF86ZQ9pz5 dGUShQb0aU8pWXmE8gmFpkObH1W7qdNmpEXzp9HECUNoyIjp9G3mHHSX+xk2qDudP3eKlYUlFCtW bFYCoqi+mjeuSokSJaMEiZLQ5g3L6eXL5zzT1ZC6/NaYDrCimp4V0vAeHjRnxnhazsrDhL+XqnqO /qTLkIlnbz/S6OG9qEOXAbpCa6w3ZlQ/NleYwEpwOqWoTp44gnr0HkGVqtQJUv+zpo/l8x5KmTJl Uwr7JN4uV7E69fljnLFbh9v4TOrWb0bj/xxA+/ZuM3swMFa+z9w7tmtIN25cZeU8LT19+pgV1r5U 58em1O63vnT+/Cka3L8LZeTxpE+fWVVdsmAazZw2lqJGjcYPALXVvmNH9tKQgd1o9IT5gZTPf84c p1bNalJ8VuYS8ud088YVtp8dTENHzaD8+Yup+s5cU1cun6dfW9Vlhe4V+SRIyCYQo9S1oRoI4p/r Vy/R8ME9KHHi5FSwcCm9lUkT2DwhQxZq2vw3mjV9HD15/IgfBl6p7egxYxGUT0d1oXzaum7x0OSu z1oftGwIASEgBISAEPgPCbjscOTqWI8fO8izjN/SivVHaOGKvVSgUAlWMKcSZtEsBQrKe14K3rh+ mX7oNM+o3bp1g8pV+F7tGzO8N/n5vaU5i7fTqLFzafm6QxQ9eiwaNfx3vQ42dm5bT5OmraTVG0/Q T43aKmUSs3VT56ynQcOm0OJV+6k0KwaQMuWr04p1h+mvKctpPJsBwFbz6OF9dO7cSXXc0Z/KVX+k PPkK09LFs+iH74uqWS/M8GmCc4Di+VPjtjR30XaavWAr/TV5KcWOHU8VcbX/KzyDDKWsza89aOLU Faq9Tt0GsrK9lPbt265169Trv+woVbdeM0qcJBmNYwXZljf4aOb+gGeOp89eR1NmsmPOyv1K8Zw/ 52+eMd5HxUpUVEr1ru0b9H6P8iwvZO+uLfq+XTs28nnHpVy5TeYJ+gHeiMX7hwyfQguX7aHR4+bR /KW7yMcnIS3iBxSjOLqmxv/Znz7yEvqcxdsU779nrGJF9qpq4l/619hUoG2cI2bBtf9XmbUzkjxF Glq8ch8lSZaCcvK5YXvarHXOVDUrY3nduvOzNutI3ggBISAEhIAQ+I8IhLjymYJ/lDt3H6JmA8OH C0fFipdXM44P7t8LdMppeCYzLf/fyl7jmqxfu0QpK0WKl1Ne9DvYqQkOIDGix1RFokeLQfnyF6Wz Z06YKbQNm/xK3/AsHMQzgifPgMZRS/e7ub62T2ujRMmKens4ljVbXlXmzu2b6tXRHw9ech81bj79 1qU/L6n704B+HalBnZJ086ZJ4dm6eRVByatUxTT7h/aysSmCNoPmav9Y/o3CinRNgzNTeV4+9/Ty osMHdjkabqDjXuxk80uLTrxsfpZWLZsT6DjMHLayYxhm8aBkadKsRUfy8orIXv6rKU6ceMw7K+3n 2VPIK55VPn/uNOUrUIyOHduvK7VYNodyppk7aG3hNVGipJTbYDqAcWHm78H9u8ZiZO+agtK/nxXw Euzwk8AnkaoHE4imLX4za8PWG5wLIhto/wcP6GyraIjst7xu3f1Zh8igpVEhIASEgBAQAi4QCPKy O2bIoEwaBQqWEsN+Ty9PYxGKHiOWev/61Uuz/dqbUmzviVm9u2w3lzBBYtq9cyMraSUJigiWYeGd PX3KGOVxr9WBnSaWveFlrkmCBEm0TfWK2b2j7NXdsd3PhGXyH+o1p/LslQ+BTd782RPpECtuT548 JL+3b9V+zJ45K1BAEQGg2vcNaC7PcsLrv2eXFjSdZ1pv37pG3t4JKGnSlFabc7X/2zev0fPnz6h0 kQxm7YENlnyDIrD9nM9hsqb+PVJFKyDDZ3iLxw++UASNAjvOePG82aTCpKQXZPvMKZNG0LNnT+jI oT1KQf6leUdq1KAinTpxiHzYPvfypfPUsPGvxmbMtg+ycopwRzjHVy9f0jM+z4QJTUqkVtDeNXWf FVVcDylSpNaKq1d4sUPC8T97UqNWQ2rb7tMsukeEIN8i9rqxeczyug2Jz9pm53JACAgBISAEhEAo EHD5lzUuKxsQX7YBhHJoFDjyROOZyJgBCqbxmOV2OINyYzxWgR2FJo4fQht4xhNhfu7euUUV2GEF EjFiJPVa76fmVJFtJY0SKVIkNXuJsE3WBLaNcKg5zk5Fs9mms3ePNuTLCi4UobYtatMLVpga/dKe kiVPo5aXu/7WxFozDvdhRq/Bz23oypXztG71EqXYhg/voWxJbVV2tX/PiF4UN158+nv66kBNxmcl N6gCpatFkxo0jxVx48cTIUABe8fmDpbyjp2nogfMQpcoVUl9dnhgOHn8EH3DDlWZ2A7Xm5fOsdye IEEiZfdbqEgZy2bU+x3snNSFuVepWkfZ4kaPEZPGje7PdpQPrJa33IlryiNg4O9YEQ+KePK5IryS pWjX64cgRGYITt2Q+qwtz0/eCwEhIASEgBAILQIuK59aOJ4tG1dQvQYt9XEisPzhg7spRUrzGSe9 gJMb3rxUmjV7HtrGQc7v37tDiRIn1cMX4VgMVkjgoJQ4cTInWzQvhuVu/G/epBorRBuoVJnv1JJ9 lx6DdacYOKy4IrBfxdK+UTxYCYXCi/+Jk6Rgb/917FRyS3nna+VQz5cdpGAy4Er/yZKlZuV8mVJo LR8AtLaD8pojZwEqzJEDFsydzLOWJicttJMoSXJ1HrC1/N4Q3xUe2HjgSJ/B5GAEr/TkKVLRHvaI x7Eq1X5Qw8iZuwAd3L+DHYkSUJZsudSMqLXxwXM8AT/QdO05XD+McTx5rL91uBHPOyFF5QcgZDMy CsYTHInNZgWQ+/zAogmc317wzKxRPMKFDzT77GxdYzvadkh91lr7X+sr7r2Txw9SxoxZ9EgMXysL d533tasXlXNhfL4HRYSAEBAC9gi4bPMJm7xsrBzCax1exPBQ3s+KRYe29QlfPu4IFl+2fDU6d/YU IctOcbbHNAoUms0bVxG85B8+9FVLvLt3bVKZlYzlLLfhbY5yyOYDJw6lwPIyeMzYcQgze1AOEZ4H Tka9un9Sqi3bsfa+Qd3S7OndicMe7WSv79M0e+Z42rhuOcFOFUopluIj8Guvbi0Jzkdg1qtHK/Yw 7x+k/qvVaMDmCzHpdw6KjniiSB0J9jOmjaHr1y6pISIzT+miGQIpYdbGb9zXhmc/X7C9Jpy8NMFs bkW2V0VCAPRx6+Y15ZDze7cW7E2eiKrW+BReKV+BEvwQsovHcZmdy0qpJgoWKk0Xzp9h28+DVLho Wa3ZQK9wOIKCjs8Jpgjoa4/BWSlQBSs7YApStFgZFdpr+dJZyu72z5F9aMWyeaq0I4cjK02qXQnY ZAAxUeFtj7BSCB3Wqml18uMZVt3chEvG45nnCxyK6jCHEMMsO8TZuqqwxR9nPmuLKl/kWziAzeTr 4f/tXQV4FVcTHdwTKN7iULRFCoVSftxdgrs7Ka7F3d3d3d3dWrxQvMUl0CLBApV/zg277Ntn+yKU wMz35e3u3atnX5LZuTNzAp/lQoesXFj4fra64/fP3QukVdYwPO8PlYHtQ5tbp3b1aCynbBMRBEIS gbicecabdQGzRLp9g+LzLmYE/r8tEvYQ8Fj5xBKHjJilLGSzZ4yjBrVL0g8tqtM93h4fPmYO5ciZ V0cBaYtgATRKBC6DIC+mOjqog5RK3t7eSrEsU76Gqqd9NGvRhZW5OsovtHTRrFSsQEbq3/sHVVf1 p/X79qi1g4LZvVMzyp87FdXwya8sbD+0700IWPLl45nTx6hUkSzk27xqIEMTp2jC/F31qfVdpVoD laaoTfNqHGhUlKZNGsFBUT7U7cfhqgqstH0HTaQ7t69TI/Z/BGb45wgmqKCMj/yXw0bNVimW6tcs QQXzpKHqvKYdbI2O+Na38cGD+8ovNGIkW4usNmcc4c+oPQ+tHAFFdeu3UpdeBpYqbMmXLV+d5jBz k0+53OyqUF1ttyM7gHGbGsw+T548URZr5EuF5OEMB8g08Pr1K5VSSxU6+GjYpB2lZ0tUB9+6VCx/ BjrAW/XlK9bSvytoYuU71bHLQJWuC6mfqpTPQ2fPHKf+jD/E/H1UhW8/8ILgzMcTPr1d+Xn6+z9V PqyD+nekajWbUGbOr2rEsG6D1oo0oVXTKtSrRyCOVtrqvw+m762VZ21cw8d2jpfFNi2qEvDczK44 l/ildDqnVsOLkFmQ7gvuMuNH9ycEKoaEYJyd29bpXd24fpXGj+mnXtD0wv/oxDy3/2gaMqwgEKoI xGQXrrSdmlNUU/aZlL3b0ucLptE/0WKE6vjSeeggEI6tNm+jhAIHuHnXn+7ef25pNEQWQ6GKy1uS WhJxY0NsxSNQBcFCRkFgELajIc7qYFsMAT+an6exPc4R8ASebigLCXmr1hj8ZOzf2A4pmmDxjBM3 vp1fKiK67/thmz85QVlAXePYzvo09o9cmAHsA5mYo7YdRXOjLgKpIrFSG4+3oI0S1PERVQ5FM378 hGq7WeuzWcPySlFzlasUa4zE0epG7LT2jlwJcA/P/O5tfuNkC58RH60djlAY8FyMrgiv37AP5j// UuQoUYxVHZ6DDABKNDIU4DkjT6z2HXL2fXH0fGDBxXdIo3o1P1Pz4K7w0OpiPvfYOovvHL4nwAk+ ncbnjTLUScDbj0aM3LV1tAZtXBydPWtjHSvniRMG/rG2+ntupc/QqtO3Zxs6dHAnDeUXXrjLQIAj WNGMmKO8aYNyipgA1vKadZpTyzbdUexQrjJBRc0qBWnw8OkEX2VnYh5rG+cHRiDh0lX72MXoS2fN 3ku5eW7vZVAXg1Sp8L3KeTtgyBQXtT6MWzkyJ6RjZ+5/GJORWbhEIALnTs5SKR89T5mGLs5eq+p6 8c5T+g6N6XLvEfSoQqB7l8tO5OZ/jkDalLEptndg3A4mY2uW9HB6+OfrLIJbdQ6rZ6Dx0KZnTfF0 VUcpLiY/SmMnUJiSJE1hLNLPjf3rhXwCRcDZPwwoRca1GJUG9OGsT2P/8El1J858NIM6Pvwb8WMU 5N2EZXX2gi3GYrtz8xqNFYyKo7Ecz9wZ7lo9oyVUK9OUR+3a1dGomOM5G9sqhcPNd0rrG1Zlo7ha L+q5u486mA9SQmniCCeUGb9LWl13bd19xxw9a63vj/GoGMnY6tiAgwI1xRPrBI7hTTsqG9cvpSuc SWHh8l0eu2pAEcWuAdw+8hUoYeOXbWRgU7lf2a8dApeguPwSi3kZ04/hnhVGK9Szyta1j33Tf2Uf ZvxeQVFOxvStEOPcVAF/wLf50IEdKvMHAv3Csw8yvjdFmM3NyP52jwMzwQCGlG3oU2OIM/bjjj0N 8z/NfrN4EYPvvIggEBoI/M07fTcbtKKUYwaQN7/8PWFXvOR8/pRT+4niGRqIv58+g6V8vp8pyiie IgBKyR/7jHarJHrar9QXBN4nAvChRvqw4kwC4Urg84z0bDVrN7HLwOGqHe5tWLeESRKOUnJW6EBE MJtTjY0ct0CnjTUysO3ggLiDrNhB1q9ZrNwtYOE3K59WGK3QhxW2LrgUITAyW47v6cnjR7RuzSJa tf4omiu/d40dDtdrOUfv8MHdKGvWnPTE/zFdunBO5UhOwYxkUD41Fi34bINSF8QSd9hdCsxcs5k8 QlNArTBqjRjag9nlZqkAQ/+nT2kRZ8gAo5iIIBAaCDyo3ZQSrl1KyccNpvscTxD15g26PP9dPvDQ GFP6DF0EguTzGbpTkt6DiwD8LvNzMn8RQSAsI/D7b5eVS8OKZbMJW7qF8qajqhXz0ISxA2wIJaZO HEJR2H2kLjOZeSpX2VI4c+4GlY93AVtNw7Flf/L4QQ67AVmGb/s+6t7oCQsVixXocYMjrti64Iax acMKRQABt4MpM1bTjLn2vq7a+DOmjFB+2ROmraD5i3dQ8VKVKBL7fKOdUaBET+Xty4XLdtOEyUvJ j62gq1fMU1WsMGrBtxaKZ+16LRUb2fptJ+lrTqmGzBcmLy7jsHIuCAQdAd7puNa5H0Vlt7lkU0aS X1kfesWp/ETCLgKifIbdZyczFwQ+agSeP/NXygwyODRo3FYFjX2bK7+y1M1iMgMI6E9Ba4ugQaN7 hhEY+BtDkdN+4CupSfPW3XTyBLjEgHXs1MmjyrdZqxOaR1dsXZHZTShWrFgqRy628iFgEnMkWKMf s8ZpW/Kok+2bXKoMPthGad22J6VL95UqQh5eWEBvXP9NXVth1NrJ2UbApgY2LghcYbr3GqWCDFWB fAgCoYDASw5G/TuKl6IJec5b7iJhGwHZdg/bz09mLwh8tAhomRqGjZ6jB69BOTzH2QtASNCsZRca ydu/yCMLX01nUrNyft5Sv6bfRk7dzFlyqmuzn28SzskLhqxHnL7F6HusNw7hE1dsXfCv7tRtKG+l dyWfMrkof6GSBMYwR77lULy/TJuBNjP17nffF+TAq3i0cf0yRVds9sE2rxl+ny9fBm6ZW2HUusdB kwgyNftUI6MIgu9EBIHQQOALTpf4b8Rw9DRtNkoyfRz9ydli/jH59YfGuNJn6CAgymfo4Cq9CgKC QDARQLYDyJNHf9goggkSJVZ5Y2EN/JkDgMD2ValsLn00KI9rVy/goKD1NG/RNhozYTE9f+Gv30+a NJXKeqEXGE6Q8QAS8y1rl+GW5VNNAQsKG5Y2iNZHUaYb/i5PQVq7cj4tWTiNjh7ey0FVuxWbm1YX R1hzoVTC+om0a5BUqdNSn4ET1bm7D208K4xa4cOH4wwUf7nrUu4LAiGGQFTOjZ1wzTK60bIjPclX mL6uXpI+nzycbnXqH2JjSEfvFwFRPt8v3jKaICAIWERAY85C4FGpMoEUu2gKQgXkzgWVb+fug+lv TqdllNHDe3G+2CxsDS1OUTgHYJKksYy3bc6vXjlvk2rpF873CzIBs7VQaxSBqXIhz9glwJkEh9HK UZ+wMNau14oyZMpKLZtUprOnjzOBQyGbqr9zdouzv5ykxSv2KBY48ONqAUQ2Fd1cWGHUgnV488OV isBBy+qAzARmti83Q8ltQcAyAimGdKeAz78gv7ot6F/OTONXpiIlWryA/JjA5fV/nPLM8iKkog0C onzawPFhXNy88RvnGQ2gNF9msDwhcxvzteWOpKIg8IEgkOv7ApwzNwnNnDpS5c6FMrVw3mRmz/pN Bf4g5ZJPlfp2sx3HLDtQXB3dM1eeO3uCyktbvJSPIjWAJbVJ8w7mavo1cvhCwJ6F7WoE9CRNlkq/ jxMjo1WGjFk5D+89lZjezIZl08jBhWLSYvcCMKTB1/PIoT2KcCFZctvx0DQ+p1VKwLl32zBJRnLO hwjlGflts2XPzexk1VVOWgdD2BWBUWvJoumKPa19lwGcBSANByTdob2clqkABzEish/9zWayiYF9 21O7Tv3oKUfhDx/SzY7ty65zKRAEgoBAHM7i4HX2FF0aPFEpnujitm8Pird9OyUf+iNdnrI0CL1K k/8agSArn9jm2cS59cAKU4L/cJsF1gr88cQ2Vo5v89gwH/3CPluXOGLSkSDJe272WdIE0Zega3zy +E/KmCkb4R+SObm0Vjckj1DesAaz5M1XzMbnCkEMyHd3jrcFEjHVZM7vCtjxzlupYxwHFIJIobJg 6S5jsc050rT8wdGlGp2puY352lzfpjO5EAQ+QATwez5o2HTq+2Mbat4oMN0Sclf27j+W/pe3qNMZ hw8f0YYVy1FFRLVDevQaSdOnDKcFcyerIJqyFapTPc4rqomZUSsjWx8LFCrBqZaWqJ9OXQfaKZ/w 1QQbVr9evooNy5vZ0ho368D5R3fYsGGZ+8aYGlsWGK+82e1g7+5NTCs6QU0ndpw41KFzfz2FmrE9 sILFNUbMWJQ9Rx71d/c3zl86qF9H5aIA1i9nLFpg/UJfEI1Ra9igLgT2NAi25L9Ml1HP5ZmYqWZ7 9x9Ho4b1ZEa3YiqdU92GrenEsUP6GKqhfAgCwUWASU2STRpOT5hJ7nGJinpvfzFJy+26DSjZ9LEU k/WDZwZmRb2SnHzQCASJ4QhJmQf0bceJj09RBo5Am7Noq75IMOB0aV9fvaWnz5iZXnIOviuXLzAV YWNq/9Y/YxjnooNjvFlePH/G+fWy0qz5m9WtVSvmsrN9d8Ufjj+s58+d5n86RWjQiBkOI1tBfYdc d/U5MtbsDG8ey931qOE9adnimRQjhu2WXc++o/mfTynV/DErxG2aV+FtwKvK2d/P7y4FvHrF/zCn 0be58lmuY54LOJLdKZ8tmFf8AadIWbHusGpubmO+Ntc3jynXnw4CYYnhSHsq2Na1upVshakK/aIe /CTxN+v2zd9VsnRzMI4zRq1HzLry5k2AzYuoNlftiBd0V2xYzvrGy6qRcMAZc5qxPXJzzmJr5MZt p5RFVpuDb8tqigFt8fI9qsjcNwoRKQ/F1PxSb4VR6y4zeWkMc47YvtSgH+CHMBx9gA/FyZTC8e/D v/x7yl9SuxrhWL/4l3cgRD58BILNcLSLuY779fSlgoVLcQLoALsVr14+h1ODbKehI2fqStpQfote umgGlWMaLGwld+42WP0YG4N2sgpzhmvc8LA8DhvUjXyq1qdOXQPz7oGvuXeP1rSZozjLV6ptbK7O L1z4RVkwyjIffHCVT9CC4m0f+fKcyQj2Q3ngd5+WMNUefNCQ0qRJ/TI0eEAnPRG0lTrO+ndVPpE5 1UExaFU8rW+1X6knCLwPBDyJPDcrkM7mp9WDpdKYoshYXylkgUZBY7GyENoUOLhwx2jlrG+j4olu HUW3o9zYHgo0Xt737NpIRYqWVzS2v/JuDKyfuXIXQHUl5r5R6CxFlRVGLVhBNXHE9qXdk6MgEFQE /n1Lxe2ovSiejlAJG2X2rxJu5u3l5U3jpyzjbZfx/IYd0642/JKSJkuhK56ooG1j7dy+zq6+VrCI fbmwXVa1RiNVtI4ZRJC6oxX7dmiC7X3kpNvOlHtmMVPfrV21gH3DrujV8FaO9Cwzpo6ghfMn0zmm qwuOgFXl8MHdKpEzFE8I/KwqV21At2/doDMcuGCljqs5YM6w5E7mJNqg2DPmJwS13v6921w1t7nn qL47TEDHt3zpLEXLB/eHObPGKVaWhw/v2/StXYBLHdv7d9hlwCiwtqAfvGBAwGMPjuwpvC48J0f9 4XnOmDZSrX3r5lUEK48mxnnhZWg8p+AAnSgEOKHfOTPHcu7Cq1oTOQoCHzUCVas3orz5ilL/3u04 Gf+XVJgT8jepX5bpP3PzVv2Aj3rtsjhBQBAIewh47POZ49v/uVzl06eP7SJFEzHneZw4n9kog8ZO oExAwchXoJgeoXme39pTsOM8nPqNkipVOsK2v1lcUd9h26pTu/p0g+nzUjHVHLbLx43qR9VrNaF2 HfuZu7J0ffnSOY54fUpZmMrOKOnZJwxy9cqvnCD7H7d1MrMviyOB4tqgVnF6ztaMSJzDbw5vqRUr UYH6D56sqhtp/xy1N5eZ61vBxCodnzZWBPYNmzxhCF1kC3TPPmO0YtrGz3bEkB70Tfbv6R4/iw5t atHTJ48pNVvBly+ZTVMnD6Nho+bQV5zwGtK1YyM6emQfJ8LOpHzRFs6dxAEeC2jy9FXqvjYvjLNl 40qKzT510aJH52CUSU6pCFVD+RAEPlIE8HdyxNh5hK3ye/fuKKYmvBRr1t2PdNmyLEFAEAijCHis fLpbZ1KOxNy2eY1NGg78QUTCaDCWOJJVTO0G3uIatZvptx8//oNiecXWr7UTOO8/f/5Uu9SPoL4D /3HPri0I1HcpDOkXxo7soyJO5zB/scbDPHpEL86bN50ttCWZCSS33o92Aif7a79doZJFvlbbUvBr Kluhhor0xHYagn0gsVmpNkrcuPHVJdZjpY6xrfEc1tPq7Cf7AyvHGG/MyN60eME0qlytgZ3Ca2xn 9dwTTDQ6PrCiIIisYd3Sio6vCSe8Nkp09o/NzQFhh/bvVPSH2jYcLNVIgJ06TXrq0bmp8rVbiJQw nEsR1tLGdcvw+nrRjDkbVHfFmMu7e+9Rei5D+P4OHdiVLlw4Q+nTZ9aH3Ld7C02bvY4D0bIScj4W L5BRBWRUrtZQ1fnzz4d6XTkRBD4FBLBVnjqN16ewVFmjICAIhGEEPN52d7fWOpyPLkaMmNS0fjnq 0rEh/dCqBvmwL+fDB34qMt7cHr5KUD6/zvwNBxu942p99fKl2nY314cV8AXfsyrY4sXWbDGOlNMU T7Rt1qITRWY+6J3bAxUec38VfepQlx5DqGOXQVSnfiuKwC4AA/q057QvI1TV52ythUSKFEUdtQ9Q 4kHg/2mljtbOfATtXjsO0ILiCcEcIAf2bVfH4Hx4iokrOj7zPMqUq0FQ+jSXgCdPHim6wqKMP7bO 9/K2OHI2QvGEwDf3u9z5VTAZ3AAghQqX1u/jOkvWwATid27bbueD3g+KJwSBYVapCFUD+RAEBAFB QBAQBASB/wSBELd8wuI4f8l2Fc1++9Y1ip0yLTXg1CU9u7e0sxJixTu3rVU+kqDKMwpShsCB3iyI UMU2q1W5xXNA8FCq1OlsmsBKFy9eAo5GtVVotEqob2xTiX05sQ0ORRkWP6+3VllzYuUA9m+EIDrf Sh1tPPPRTLsXN24CztvnzdZUx/6W5vaurj3FxLx1Z6TjM48DNhaknNq6aYVSIrdvWU3/Mv6ly1Sh u7dvcJDaa/bHHM9b5FP0pmCkwTOCb2gkVkphxVyyYCqnsNpPjx49VBkEUPkfUzLxRIneBTt4QkWo DywngoAgIAgIAoKAIPDeEQhx5RMriJ8gMdVt0EZfDCxhD5j2LUPGLHqZdgLKODCKFC5WTitSR2y5 37l93aYMF/BV1Gj37G46KEDQEuT1W9o8Y5XXHK0fyyKNHiyQX7IP4sULZ1XATJzPArfXH/jdMXbJ inTgnONzHjIrdWwau7l49eo15/EL/pZaSGACtwRHApwKFS3LPpoLVaDSju3rKWu2nIoeEc8OUrte c+W+YGwfNWpU3drp26Ia+bPFtGHT9hyFnEa5THTr2NhY3eG5VSpCh42lUBAQBAQBQUAQEATeCwIh vu3uaNbzZo9XeeuKFK9gc/v0qZ846vwUla9Yyy7H3DfMzAG/R2PEOvwDz58/S7nzFLbpR7twRH33 eZLkauxTJ3/SqqnjlcvnOcraTzGh2NxwcYFAJ0TbR2Z6L+QwRRDVkcN7bFog2hq0f99xonwrdWwa Gy4QFIVcgpoAq4CAlyoISysL6jEkMXE0B6TUgtV62ZJZBLpCsMdAkDIG2RKQwxTBEMYfWHYht25e U1vwtdnNoHTZauyOkZ3ggmBVNCrCvoMm8YvKXUVFaLWt1BMEBAFBQBAQBASB0EfAY+XzCUeznzpx RP28ePGMXrJvo7o+eVSlAjrLASlIafSAE66fP3+aRnOydgTK1Gvka2exRHQyLHk+HERjlpJlq6p7 yOsJRiQoiz06N2E/0AhUgf0xHYmR+g6pd5ArFLnwSperRrvZ73MuK8FQbpDGp1f3Fip5vaO+4Kf4 Y9fmdGD/drrNW8VYB9hKkFS/5tugKOTGQ7L53Ts3qdRNGGvDuiW0euUCKlaygorSt1LH0TpQBsWz RZOKKnUQFM+hAzsrJpGSpas4a2K5PCiYWO6cK6ZMlZYyMlnAnJnjKErU6DozCvooV7Em7di2nhB9 jxRLwBo4L2VKP4g3K/SwzO7ZtZn++MNPBRn17tFS3XP1gUCoieMGqjRP8Lc9csg5FaGrfuSeICAI CAKCgCAgCIQuAhE97X4H+/ANY9YhozRrFEh7tWbzMWXVQq45WOkgCdn/ryNT0FV5G4GstYPicZCj osuUq0reDqLaE3N0+Ygxs2lgn3bUuF4ZRfGWMnVaGj1ugR19pdanM+o733a96G8OZkG6oknjBinl Bml9kN4HuTnNAh9HzK9L+4b011+B+SXhxwgqPR/2/dSkAye/f8F+ijOmjlKpm0B/V6JkRerUbYhW hazU0Su/PQHVXf6CJdiCGkvNAf6Qn3+RlIaOmqWnnjJS66GZp9dWMAn/llFCO2rzNNLxaWXmYxl+ ecD3pAhvwRvTZTVr0YWZYd5wLs6hip4P7YCbxsMNy6Vv+97qfqkiWZSfK/LE3r8/XqcA1OajHdGH OypC1BERBAQBQUAQEAQEgf8egSDRa7qbNqKp79y5wUpFXDtrp7GtI6o3433tHFbAiJEjWWYtckZ9 h8h6BL3ET5DIUv47zO8+J0Z3tw5EcWOLNxGzfWjR6drctaOVOlpdRH3DpxIWSmy/v2J/VeRKNQr6 g1KqsZN4eq315Q4TR8/IGR2f1ieOsGZ28K3LuQfncvLrYsZb6hwJ8++wfyyyCGj0fMZK+A7dZ3/a z79ITggm0qgQtTqO5oV78CsNYF9eWMEVA4zWQI46AmGRXlOfvJwIAiGAgNBrhgCI0oUg4AECZnrN UFE+PZiPVP1IEejYti5dOH+G1m4+oZTHj3SZYXJZonyGyccmkw5BBET5DEEwpStBwAICZuXTY59P C2NIlU8cAViejxzey64DpUTx/MS/C7J8QUAQEAQEAUHAjIDHPp/mDuRaEDAjENPLi2bMXU+pUtrm VjXXk2tBQBAQBAQBQUAQ+PQQEOXz03vmob5i0GoaaTBDfUAZQBAQBAQBQUAQEATCDAKy7R5mHpVM VBAQBAQBQUAQEAQEgbCPgCifYf8ZygoEAUFAEBAEBAFBQBAIMwiI8hlmHpVMVBAQBAQBQUAQEAQE gbCPgF2qpX85/6KIICAICAKCgCAgCAgCgoAgEFIIIH+5JnYBR/7PXtPzF2+0+3IUBASBjwyBGNEj qRXJ7/lH9mBlOZYRSJQgBt3ze265vlQUBASB4CEQJ3Y0iholgt6JbLvrUMiJICAICAKCgCAgCAgC gkBoIyDKZ2gjLP0LAoKAICAICAKCgCAgCOgIiPKpQyEngoAgIAgIAoKAICAICAKhjYAon6GNsPQv CAgCgoAgIAgIAoKAIKAjIMqnDoWcCAKCgCAgCAgCgoAgIAiENgKifFpA+M2bv+jgwf3k7//MQu2Q r/Jfjx/yK5IeBQFBQBAQBAQBQeBTRcBj5fP06ZM0a+YUh3hduPArTZ82kf7662+H9x0VzpwxmQYP 6uPo1gdTdvXqJariU4r27tnudE7Ij7p+3SoaNLA3DR3STymrTit7eMPK+B52qapv2byB5s6Zrn4W LZxHJ47/HJRupI0gIAgIAoKAICAICAKWEfBY+Vy7ZgX92KOTwwG2btlIvXt1ZQvhE4f3HRVu3LhO KW2O7oWVsoCA11SqZAFq07oJ7du3izZtXKuU1RnTJ33QS2jerB4NGdyPxo8bSQMH9KQypQtRieJ5 6e7dO8Ge99WrV6h/vx/p6dOnwe5LOhAEBAFBQBAQBASBjwcBj5XPkF76ylWbaN+BkyHd7Xvtb97c 6XT61AlasWdR5AAAIq9JREFUuHgNbdm6n/buP06bt+6jr77O+l7n4elgf/31F1WpWpOOnbhA585f p0lTZtOF879St67tPO3Krv4vv5yiyZPGkt/9e3b3pEAQEAQEAUFAEBAEPl0E7BiOQhKK/fv2qO5y fZeHNm1aS5cvXaAc3+aiggWL6sMcPLCPrWNPqFTpcrRz1zZ65u9P5cv76PdxAn/LBw/uU4UKlVU5 LI2bN6+ji7zN/0WSZFS0aElKmDChuge/zOXLFrBSVZv27d1BJ04co6pVa1G69Bno3r27tHbtSqUQ ZfoqM5Ur50MRIwZm3McYR48coNevX1PadBls7qmOXXzAyhc+fHj65psceq0sWbLp59rJSZ7LgQN7 eYwAKly4OGXNll27pdbo6fi//nqWLa276cWL55Qje07Kl7+Q3l9QToDvvLkz6eefjujN3eHiCNOj Rw/RQV4nZP361RQ/QUL6jr8DadJ8qfcrJ4KAICAICAKCgCDwaSIQqsrnzJmT6fGjR/Tmrzd069YN ihE9Bo0eNZTatutMnbv0VIjPmDGJbt64rpTPA6yswgf0u+/+pyuTqNShfUtKxwohlKM7t29R7do+ qt8MGTLR7FnTaPjQ/jR7zhL6Jvu3dPv2DeUW8Msvp2nVyqUUJ85nFCNGDDVWxQrFKVmyZJQkSXKC +4A/K7316jehxg1rqe3yTJkyU/gIEZTFbsH82bRq9WbVzt1Hpq++pn/++Yf69O5KAweN0hVaYzts QU+ZPI4V2/QUPlx4GjVyCI0cNYmq16gdpPEnThhNw4cNoKxZs7Obw1MaMWwgVfKpRhMmzjAO6/F5 rJgxKVKkQPpFd7hcvHCeHGEKpXjH9i1q7CWL51KECBEpIv+I8unx45AGgoAgIAgIAoLAR4dAqG+7 //TTYfqKrYzHT1yig4dPU8FCRTlgaSohgtss2ALGVvDq1cv0WwiCuXH9GvlUrq7K+vTpTq9evqLd e3/ibe7V9NOxXyl27Njsa9pFb4MT+J+uXb+DTp25Qm18O9GCBbOVErqZt8VnzFpIh4+epQoVq6g2 FStVoZ+Pn6fVa7cS3AD6DxhGRw4foDNnTtn06eyiZq36lDdvAZo/bxYVyJeDx5pDf7MyqgnWAMWz jW8H2r3nJ9q5+witXL2F4sWPr6p4Ov6lixdUUFOPH/vRmnXbVH+Dh4xSyvae3Tu0YT0+/vbbVcLz 0iyy7ublDNOhw8ZS776D1fgLF62hQ0fOKCXb4wlJA0FAEBAEBAFBQBD46BAIdeUT1i4oI9jeDhcu HJUsVU5ts9+7Zx/UkjHjVwRr5gbeqtVkJVsv48aNRyVKlFVR9Nu2blR+it7esVUVLy8vyl+gCCEK 36jQ+rbtxFbBb1SdSJEi0mefxeWtez/atnWTXqb1UbpMBdLOcTNnru9VnZs3rqmju48IvOW+aOla GjBwOM8hgDp3bENFC+em33//TTXdsGENIRq+WvU6elffffc9FSlSXF17Ov6KFYuVIt24SUu9v0o+ NShy5Mi0f/8evczKyaGD+6hjh9ZUr25VKs1BU7FiedGgQSNVU3fzcoWplbGljiAgCAgCgoAgIAh8 eggEedsdyhSUSaOgDGIsjxQpsrEKxfb2VtfYKnYk5djfcxhvo9/m7fUvvkhC27dtokKFi7FiFYlg mYNP5oTxI2nqlPF68zdvXqtt7xcv3uXhTMJtjdKseRtlzWxQvzplyvQ1NW/uSz5VAq2pT548pmlT J9B+9p98+PAhvXr1UjU1Wi+NfTk6hwLasFFzqluvCVs5x3IUeV9q0byeCkC6xkpookSJKWXKVI6a kqfjX7v2O7d5QhnSJbXpD9g8f/7cpszdBfxF8SIQP35CatehK9Wp05CiRYummrmblytM3Y0r9wUB QUAQEAQEAUHg00TAY+UzAQePQO7cua2UQyNsfn73ycvLm7fB4xiLHZ4jQMeRVOWtd/gyrlyxhBCo dOvWTaparbaqGi1qVHVs3sKXqhqsiCiMFjWasl46SxMUPXp0Wrp8PR05cogmTxxNbdo0oVu3b9IP bCGtXrUcPXr8iNq168p+iWlUYFKTxu+slGpQix+w8LZu014FQ8FqCwUOfqQR+MeZeDp+FLZwxo+f gNZt3GXXZeJEn9uVuSoowsFa/foPdVjF3bxcYeqwQykUBAQBQUAQEAQEgU8eAY+VTwTlQNZx1HiL lj/oACKx/MEDeyh1MCOaE3/+BX2bMzdt5K1qKLhJkyajPHnyqnFwz5stpwhQSp4suT62JyfY7sZP xQolaBtbVctXqKK27IcOG8Pb4rVUVwik8USw3Y+tfaNEiBiRoJxFjx6TUqRISVs2r1eKdJIk76yV aAcLL1wGPBk/Veov2S92OQfxRLB7ATDOITjn165dszwvM6ZQ6GEJhiCTgYgg8CEjgB0V7HbA7UdE EBAEBAFBIPQRcGx+dDFu3nwFKCcrh6NHDaExo4fRKc5vuXfPTqrLEeiXL1+ibt36uGht7VYlDgBC tDoUUPgdGgXBPUjfgwTu9+/fp0eP/qTtHFkNZiVXgmhz1Hv58iUhYOfWzeuUMkUq9gX9jP1RI9Lm TevJz89PBRm1atnQVVd294oW+Z66dP6BUzvtorNnz6hoeUTTlyhRRimldeo1VhHkrVo0UCxCwKx1 q8bMhtQrSOPXrddIKeEtOEk8FNdnvNV+hbFHsvgrVy6r+S1buoi35ZPQqZPH7eZrpcAKLs4wRf9J k6VQw8yfP4utwOeVy4QqkA9BIBgIIPXXhPGjqF/fHrRw4Vz1++you23bNqvfQysvkv36dqc2/Pvo SsICE5ur+Tu797Guy9l6pTzsIRCVA3ijGOJAtBWEZyNUdM4lHY7/b4uEPQQ8Vj6xxJmzF1HRYiVZ 2RlBpUrkpxrVK6hUSrPnLqX/5c2voxAhfASl2OkFfBIxYmAaH9yDOKpToUJVtYUOxbK6aXu9c5de VJv9EuEXmi1LGsqUITm19W1Gj3nbXOtPHTm1j1GgYDZvWpdSp0xABfJ/yxbDpNSrz2B2E/CiXr0H 0rFjRylr5tRUrUpZqlylBqdoiqNb7/S5mvrU+m/YsCnt3rWdqlcrT8WK5KERwweq6PxhIwL9UmGl RQqk6xy1DxYhYIYcpYjgD8r4CMCaNWcp+T/zp5LF81Ha1IkoP0fZwxodibfkIffv31V+oRHfpk3S 5mo8AhP8OBIr83KGKfpDsBeU76VLFlDBAjn5BSXoUfiO5idlnxYCeGnE72bVyqVpBbvkgMQAKdY2 bVhrBwReXJs0qqUYtlauXGJ3PygFZiY25PYNSwxezuZrXldQsJE2gkBoIhCZM7DEadKAIpiyz3j7 NqeYkyfQv29TKYbmHKTvkEcgHAcJBUYJve37qX8APX/xxtJICMhBGqR48RJwlHRMuzbYikf+SwQL GeXFixdqSxplzupgS/rvv/+mqFGjGJvq55j29evXWXkK3Ho2BjkZ+9cb8MmrVwHK4okUR2a/VCSu v3PnFiVLnkIpnahrHNtZn8b+77KbwKuAAHYVSK7mZbynnWObHf6fCEAySlDH93/qrxTNhAkTUyyv WHqXFcoVU76mrnKVYo1RokS2CRDTO3h74m5erjBFF3/88ZBeMyZwmRD5MBCIET3w99Hq7/mHMGtf pq7duXMbv/guVm4zmBP+Bvz99z92v2vlyxbhDBnxuf5WQlBc9x59XS6hfr1qypUHKdCciXmsNbyz 0bJ5A9rHbGZpvkzrrNkHU+5svuZ1fTATDuWJJEoQg+75eRacGcpTku6dIBCO/4ck+D4HvUmXlv7k 1IKQKEzL/Vmj2vRo5AR6Vauuk5ZS/CEhECd2NIoa5V3si2Ozl8UZw6/PWQQ3ughkD3o3mNYtfCE1 cVYHPpRmP0qtDY5QNlOkSGEs0s+N/euFfAJl0tk/CihhxrUYFU/04axPY/9WFCxE8DuSoI4PhdOo dKLvw4cP0sWLvzLF5wFHQ+ll5jXqNwwn7ublClN0AyutiCAQHATAorVu3SpC+jT4F2uCvwGBfz+0 EmJL+0I6f/E87d49Rymf7+64P8ML77JlC1kRvUbZvvmWivHujvZSe/DAOyY2bP1bZfDav2+PGtgV yxsquGJtUx3wB8gbdrECjgwViRN/TuF49wg7FOXKVVJVMC9HLGmu5mtcl1WGuZBmVtPWJ0dBwBEC //L/EP8f2pF3v54UhV/6AkpXIC8+D+DdNVE8HSEWNsqCpXyGjSV+erN8yFSko8dMcaqcf3qIyIrD MgL79u5WKdYqVQpMjeZsLfB9Hja0HzVr2srjQLxnz59RiWL/o2fsyhI5chQaN3YEk1BUpkmTZ6vh jExs69ausMzgZYXlzR1rGyYA/9buXdtxDuLcit3t3Llf1Itdmi/TKeXTFRuZq/ka13WAFWV3DHOh xazm7JlKuSAABF40bU0xFs0nr4F96AXHNUTgXc9HU2YJOGEYgSD5fIbh9X4SUy/LlpASJct8EmuV RX78CFy+fEFZIOfMnkp5cmeltGm/oP99n40G9O9pQywxbEg/diOJohjNPEUFGTTy/C8/HfnpLO0/ eIKaNmtNa1avYMYv+614Txm83LG8WWFtG8l+5NVr1KHlKzbS9p2HqFKlqiqIcfWaLWqprtjIrM7X HcNcaDGrefqspP4niAC71z0ZMJQi3rxBsUYMphdVq9Ff2bJ/gkB8PEsW5fPjeZayEkHgo0TA399f +XdevnyR2rbrQpMmzaJ8+QvRpIljOOtGII3r5UsXmd52JvXmIEKzj7kGyuvXb3jL+oX+A39HTcDE hny32jZ7y1bt1C2QXARXXLG8wefdHWsb5g3XA6RY0yQXux+gDIFYEHdsZFo7V0d3DHMhyazmah5y TxBwhMCbLNnon2heFI5vvnnLXuionpSFDQRk2z1sPCeZpSDwySIQ6W3Ghjlzl+l+4KCmPXH8KG3m /Lmdu/SkHj060Pff56XiJUo7xakAZ4S4du03/T5y69ap20hdm5nYEiRIoDJu3L9/T68f1BNz30aW tzdv3rhlbQP1L2iHVy5fTIUKFqW48eLRsqULVZlVNjKrc3fFMBeSzGpW5yP1BAENgVicLpEihqeA b3JQrNHD6VXlmvSvIchWqyfHsIGAKJ9h4znJLAWBTxaBzz6Lq9b+xx8PbLJEJP48CZ3jvLpgETuw f69i/cqV812ieCh2CxfMoQ3r19DW7Qdp0ZK15O//jvQgZao0LjF9/TpAMba5rBSMm2B5s8LaBgtt VKa8vXf3jkqphiG/TJueJk6aqY/ujo1Mr+jmxBXDXEgyq7mZhtwWBGwQiMC5saMvXkRPO3engKLF KX7R/BSDU609GzjMpp5chB0ERPkMO89KZioIfJIIfJ05q1o3Ao+qVqupY4CtdqRGA6Xv4CGjOG3b X/o9nPTu1ZWy8FYdrKHRY0TndHApbO4bL/788w+VFkzLzgBfT2xpf+kkjVJIMXhZYW27yNH7J08c o917fiLv2LHZNSA8JUwYSHOMNVyzwEZmdb6YjzOGuffBrGZ8JnIuCGgIeHfrQH8nTUIvWrXlPEuR 6aVPZYo5eza9rN+Y/nbyO6q1leOHiUCYUT6RBgWO+5kzZ3OYU9QRvOY25mtHbaRMEBAEPiwEChQo QqClHcX+nUmZsCFhwkQ0ZfJYZs26Qr37DlZ+mvXqN7GbNFiQvvo6Czm6Z66MfLSVmHK3+4/9mGDi M2Ys81XR5D5V3im7xjZGBq8YMWIqcodUqVIbq1g+B2vbrJlTKDMrymXL+Sif1WPHfqJrv1+lJhy5 j7RKyAtctWoZSpMmHUWLFpU+ixOXvsudl6rVqG3Dkla8RFn2Bb1D7du2sBnfk/mCYa5L57aK3hhB SJqAWW3G9IkEZrX+A0cwlXJause5jeH6ULJUOZ7bO59UrY0cBYHgIhCVMz1EYaa+P2HpZ8UT8rRn f4q6aQt5de9Aj5avD+4Q0v4/QMDjgCPwIM+dM93uBwnWjYLISKTtANvPjh1bVTJ5432cW6mjtbl6 9RJV8SnFTDnbtSK7I1KWgCbvzFsmBHMb87W5vl2HUhBmEcBW5ZLFC2jVyqUO1wBqVqSvAUsNqFqx detIYBFbtHCeiqweNXKwojM11rPaj7GNnHuGAHJ5TpuxgCKz76dPxRIc6Z6VdvLflDFjp1LRoiWc dgYGrggR7PMMmxuAwax4iTKU49tc1KhBDapQrii94LRNSGgf8y17ipmJzSqDl7kdxjazvLllbWNW uHjx4lPq1Gk5Ij8fc9B/rb6vnTq2pl4/drbEkuZsvo7m54xhzgqzmhlbuRYEgoUAk9R4DRlAATly UgC/FGnyL7+MPWvWjKKyu01k/hEJewh4zHDUk//Y4S09Viwvm9WOHjOZ337LqrJ5c2dQdzaTf85b OHH5j+YZ5h9HgMD0mYv0SFQrdYwDXGA6ykIFctG06fOoTNmKxlv6ORImV61ShoaPmEA1mfXA3MZ8 ba6vdyQn7x0BvKgkSJCQLT+BCbODMwE853Zs+TnNfkKZM2ehLdsO2HS3Z/cOasOMOUjLkyx5SqY6 PceBLJFp9dptNkQDSGzerUs7ZVlLmy4DPecckAGvX9OevT+p/qz2YzP4B3ARFhmONNgQ4W3edtbu mY9WGLzQBjsiWsJ6vGy84u32z01kEM6Y2NwxeDlr54gxDS9MjljbkFtz7JhhdOL0FV0Zxrzh53mP A6K076M7NjK0Mc/X2fyAiSuGOWfMahgjLIgwHIWFp/R2jpyhghliiNhH2k74JZGEXtMOlg+xINgM R6DLREoO5JpzJLCMduvaXm11DRo8UlWB9ak1WyTBHlK7dn3eLnNfx1Hf7spgFfj9+h+6ghvS9d31 J/eDjsD8+bMpDaeSCa7yuXHDGvrBtxmV4m1A0HqaBf9UsaWaPEVKWrFys2K9gs9c6ZL5qW+fbjRn bqCl9MrlS9SxfSsqwNHFSDSuMemgPcRqP+bx5Tp4CJhpaV31ZoXBC+2NTGpacJO5X2dMbJqPqLm+ du2snSPGNCjAKVKk0JrqRyiBz549Uzz25StUVpS4p/jFCi9Z+QsU1uu5YyNDRfN8nc3PHcOcI2Y1 fSJyIgiEJAIGRkS7bkXxtIMkrBSEuM/n4kVz+R91ROU7pYFQyacaDeXItPVrVyrl00odra2jI/7o ruO+8I+iRMmyyh8M9cBwsmzJfOV/BD8pd+Ks/hVmUDh4YI/Ko5eGt7qK8ZackbveKmWeNj4sZE+e PqHy5X20InU8dOgAPXzop9PjuaPYe/DwAW3ZtI4DDH5X23BFi5a0oQvV5pUufUaaN3e64q9v3KSl WsdaxsuPrSSZvsrM4/noypTNhPjC3Rio747mD4rZzh1b6Ny5M/xSGpMpEfNQVicJgf39n9FaZox5 xlHIt2/fpAUcnRyD/6BUrBi4xeJJX5hb7Nif0dJl6yh7jlxUvmxRpi0MzIOIexDQjt68eZPate+u FE+U4R9+4cLFlO/a3/xyheCMqVPH8z/5qDR23FQbrDRFxWo/6F9EEAgOAg0bt6Djx45S+3YtCFvt 0aJFVxSbpUqXowEDA1/wg9O/tBUEBAFB4H0jEOLK5+nTJ9jxPK3N9hAWlS5det7e/FWtz0odZ0As YeXyp6OHOeFyGnbI/53GjB5GCxauVMrNrZvX6ccendT2rbOteWO/jupPmzaRBg/sTQnZpwR+VjNn TaVhwwfQ3HnLKD0rdRArlHnGcfbv30NTp4ynnN9+R0b+93Ztm6tcfeBmdkexB0tH1cqleW2JKBkH XVzlYIuhzOgCS12BgkX0eT19+pQDBW7RS96qgJU6b96CVLFCcW6TjJX05LSWuXH9WRF2FIRhZQx3 NH/w/a1frxr9zsESSAfz558PCYEfCJzo22+IERZ1fv/+XZo0YRRvB/5Bz/nlAefeseMo5dPTvtAh rN+u5NGff6rbMWPGsKkGhX3FiiX8nfqNfevS0GF+MUBfWh5Fm8p8YbUfczu5FgQ8RQB+p3PnL+ff W3+6fecmhedod7iLWLXsejqe1BcEBAFBILQRcOBE4XpIbA1duXKJMn+VinJ8k56tS0VoMXOuamwh fzx8qJQHcy9xODrzKf/xhFipY26vXV84/yut37CLtmzdTzt3H2E3kPA0aFBv7XawjgiAGsABKNVr 1KUjR3+hDRt30bZtByng1StWajva9O2OMs9YuUbNekoRXM5JojX5mS0ZoPSrXDmQr9odxR62y2bO WkwHDp3kfIVraP+Bk6zIfk7gZjbKkcMHKEf2nOwfdplOnLrMlsTZypK4mfGaMWshHT56ljmr3zlu G9taGcMdzV/v3t2UpXXTln20cdNuOnzkF6V4Tmel/vDhg8bh1DkiZA8dOcPb4KkoT5786nzzlkAH ck/7suvcQQHGw3dm21Zb5hotTc/Tt4FHSEb++NEjqlalLH2VMYX6vlfkaGgo6BCr/TiYghQJAkFC AFvdeAFOyy/yongGCUJpJAgIAh8IAh4rn3XqNOScemNo4KAR1Kp1O4rAkZgd2rekkSMGqSW9fPmC IvG2u1kQ3IF7ECt1zO21627d+lC69BnU5RccFFCYA5mOHjlE2C4NrixePE/xJXfv0U/vCluyUNYO HdyvaPm0G1A+wJkMnyko5Eg18pQtikhzYhbUzcasDHAV0GTViqVsWY3HUbZlVSYAdxR7SZMmo7z5 CmjNlV9runQZOfH0Xb0MJ5+zQjpy9GS1dYwtYrgmPHjgpytbKANjiiNxN4Y7mj+4DWzauJYqMu80 1qxJx04/quCeDetXa0VujyHZl3EwWJ5r1qqnrJylSxWkZk3rUdHC39MwdguBRIwUiRORP1MvC3Dv yM5RluMnTqcfew6g+/xs69b24ef8VFmw3fVjHFfOBQFBQBAQBAQBQSAQAXst0Q0yUPw05Q9V6zdo SiWK5WUfw5nUsVMPFQX/7Pkzu14QQYr8eRBEyrurY9fB24IoUaPY3ErBFjMwmTzwu29THpQLWLsS cPJmo38n+sE2LAT3EWwFcUWZpyqYPnzY7xUuARcvnFeWC3BGF2GfTSiDCMB6zVHUE8aPVNvzWtM3 b14rJejFi2dKYdy3dxfNnTNDzePZs6f06MkTSmKKyvX2jqMCErQ+mjVvQ7CGNqhfnTJl+pqaN/cl nyqB1latjvHoagxwZrui+cPasNWfNm3gy4HWL/AEXeGtWze0IrdH5DgMqb7Mgw0bPo4KciARrNdI JA4lEvzhQwb3VW4NkSMH5pKDEg3qRk28vb0Vjrt3b1f+u+760drJURAQBAQBQUAQEATeIeCx8vmu aeAZrH4ZWak5yzR3sFbFZn+9a9d/N1ejO3dvKyscblipY9eBk4KAgFfqDqx5jx8/clLLWjHy771h JdAsL1hBgWjKs/m+8Rpbuo6kMierHjyoj4r4L1S4uErgXLVabVXVCsXels0bqHGjWuwSUIf9NRsr 14ZBA3pxgJCfo+H0MkTVLuUkvEfYOjx54mhq06YJ3eLAnh/adtLraCfuxnBH8werIcQc5IOyVxx5 7s1MNFYlJPtyNCbSgmmpwXC/A0e2w2qsMceANQdpaYyCFx3IE8P3zF0/xvZyLggIAoKAICAICAKc OSskQMD2ZLLkyZXF7bvc/1O+jIgY1wTblGd+OU2FOKIYYqWO1tZ8xFhGOca+k9h+dxYYYqzr7hwW zjt37ihLpLHu4UP7VRCTlQh6YzvjuZeXF+XPX5g2cCqgVSuXsI9jCo4C/15VMVPsJeeAIu0HFkPI mjXLeZ1f0IiREyhf/kKKNjC6B2kmMBaCFnJx5Pk2tro6EndjaDR/ixavYX/SS3SS8w7u3fczfcUR 9JDkHAQBZffo0UM23SM6/oGfH331libR5ubbC0SYPzdYzIPTl6P+XZUhwn/TxnWsjJbXqyGg7cTx n/VrnGj+nmnZ3cGROOrHUT0pEwQEAUFAEBAEPmUEPFI+Hz36k5oztdr27VvoOgfLnObk8b5tmqpk 3s2atVE4Vq1Wi2KyotW6VUOVHgSKR9PGtSkSM43UrtvIch1nD2XC+FGKlebcuV9o9KihdIDZDWAN DAmBCwHmDvo4WAp/58hnMDRt37aZmrfwDfYQ1XieCDJCxHmZMraJ8kGxt559IsG2A9YcYA2cEagD iRs3Pm9b31JlYOMZP26kYnlxNykw+KAfbC8joAoR/infWvDMbd2NAeVbo/lr1bIRWwtbkC8nawcD EHxu4f8Kay4UOczvGufPPMi+sq1aNlRWRfgLOxP0i2eKxP/APqh9wfqN9vh5xknhsW6cH+UMCVpQ 3Px5M9VYiKaHH2oFTsmEl4O27Trr06tSpYaibwR++K4Dw+HD+qmsCtpLg5V+9A7lRBAQBAQBQUAQ EAQUAh5tu0eNGk0pRqCg06KDwWKE4CMobhBYIefMWapy0pUtU0QF4yDlzoKFq5Q1z2od1ZnhA+lF ICNHTlSpjyZPGstBN5GpWvXa5PtDoNIAqjhIhAiBy/L0GgoQ5t6lky/zPBdXfSHd0o/MI2tUPh1R 0pkp81Rj0wcsv+CovnXrpoqoN94GxR78PhH40qtnF3UL2/z1GzRR523bd6Hjx49SvTpVFKbZs3/L vor16djPR/RuHM8rIjVvWlcpYaiYM2du6tVnsN7GeOJuDASXAY+Y7LOLNETw40X6LOQeRE5PfA96 9R7E3403NG7scOVmgJyv33zzLc2es8yldbpVmw7UhN0KqnA6KWx/HztxMUh9rVm9XLFrGdelPcuf j59X38+FC+co7mrUicSuAvnyF6T+A0baJOBu0LAZZ3W4rChi8V1DwBwCvkaMnIRmShYudN9PYE35 FAQEAUFAEBAEBAENAY/pNdEQ1HDIS/lZ3Li6H6fWofEInzkE5sCq5Eys1NHagi4PKUZgZUM+xi++ SGqXcsRMW+fptTYWrIvPmVXETLOH+84o6cxjaX0ZjyVL5Cc2wdHmrfuMxfq5M4o9rQLoBaF0I4od dZGEHYFAEGfzAm6weMaLH1/522p9OTs6G8MqzR/6xTO6eeOGspRaTQuDtSAoKXHiL2yea1D6crY2 rRxrRF7RZMlSqKAvrdx8BHbIm5o0aXKH9az2Y+73v7wOy/Sa/yVuMvbHg4DQa348z1JWEjYQCDa9 JpYJv740X6Z1u2IzlZujBlbqaO00JQb+gVoEunZPO5pp6zy91vpBAJOzlETYEmb7qlZVP5rH0m+8 PYELAvjGe/d1bHlENQRwpWB/UGdipBdEXU3xRH1n8wJuVp6XNqazMazS/KEfPCNX69DGMh4R+Z8y ZSpjkToPSl92nZgKjGs03bK5BHapUqW2KTNeWO3H2EbOBQFBQBAQBASBTxmBIFk+P2XAgrP2rp3b 0tKlC+j4yYsuLcbBGSM024KOtFXz+rRz5zZ2bYhgQ/M3fMREuxRVoTkX6TvoCIjlM+jYScuPAwGx fH4cz1FWEXYQMFs+Rfl8j88Ovp7YKkcy97AsQvMXlp8ekSifYfv5yeyDj4Aon8HHUHoQBDxBwKx8 ehRw5MlAUtceAQQbfQyiaP68HKcb+hjWJ2sQBAQBQUAQEAQEgdBDIDCEPPT6l54FAUFAEBAEBAFB QBAQBAQBHQFRPnUo5EQQEAQEAUFAEBAEBAFBILQREOUztBGW/gUBQUAQEAQEAUFAEBAEdATsAo40 Fhi9hpwIAoKAICAICAKCgCAgCAgCwUAA6SE1sQs4Mt7UKslREBAEBAFBQBAQBAQBQUAQCAkEZNs9 JFCUPgQBQUAQEAQEAUFAEBAELCEgyqclmKSSICAICAKCgCAgCAgCgkBIICDKZ0igKH0IAoKAICAI CAKCgCAgCFhCQJRPSzBJJUFAEBAEBAFBQBAQBASBkEBAlM+QQFH6EAQEAUFAEBAEBAFBQBCwhMD/ Ady6njPd53s5AAAAAElFTkSuQmCC --Apple-Mail=_037F378E-7E52-4E7F-A07F-BAA9512A117E-- --Apple-Mail=_4C52B2F9-551E-443B-A4E7-100CDFE5B8A5-- From nobody Thu Jul 5 17:10:28 2018 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 A7136130DC9 for ; Thu, 5 Jul 2018 17:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dmi-oHaFq8p7 for ; Thu, 5 Jul 2018 17:10:22 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 995BA1294D7 for ; Thu, 5 Jul 2018 17:10:22 -0700 (PDT) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2018 17:10:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,314,1526367600"; d="png'150?scan'150,208,217,150";a="69033442" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga004.fm.intel.com with ESMTP; 05 Jul 2018 17:10:20 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.126]) by IRSMSX104.ger.corp.intel.com ([169.254.5.212]) with mapi id 14.03.0319.002; Fri, 6 Jul 2018 01:10:19 +0100 From: "Macieira, Thiago" To: Laurence Lundblade , Carsten Bormann CC: "cbor@ietf.org" Thread-Topic: [Cbor] PR for improving epoch time (tag 1) Thread-Index: AQHUEjKnmMUhRax/GUGK9AzwNH+4u6R8O6gAgATcB4CAAD31rA== Date: Fri, 6 Jul 2018 00:10:18 +0000 Message-ID: <6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47@irsmsx105.ger.corp.intel.com> References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org>, <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> In-Reply-To: <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.22.225.128] Content-Type: multipart/related; boundary="_004_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 00:10:27 -0000 --_004_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_ Content-Type: multipart/alternative; boundary="_000_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_" --_000_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Laurence I don't see why you need to talk about the unsigned width. It's encoded as = a CBOR unsigned number (major type 0) and therefore uses as many bits as ne= cessary. That is, it has needed 32 bits to encode since the second day of t= he epoch and will continue to need only that much until 2106. If someone wi= shes to represent dates beyond that, they'll need 64-bit width. But if some= one wishes to encode only the epoch itself, they need only 1 byte. Similarly for negative: any date prior to 1970 will require negative number= s. So if you want to implement the minimum, you implement CBOR unsigned and ne= gative, of all widths. Any implementation not supporting 64-bit width integ= ers is not compliant. They may be able to get away with it, but if they fai= l to parse wider data, the bug is in them, not the sender. PS: double has 53 bits of resolution, not 52. ________________________________ From: CBOR [cbor-bounces@ietf.org] on behalf of Laurence Lundblade [lgl@isl= and-resort.com] Sent: Thursday, July 05, 2018 14:23 To: Carsten Bormann Cc: cbor@ietf.org Subject: Re: [Cbor] PR for improving epoch time (tag 1) Hi Carsten, I=92m definitely after tightening up tag 1 here (and exploring as an exampl= e around canonicalization, variation and options in CBOR). I=92m not a tim= e geek, nor do I have any use cases other than tag 1. I think tag 1 time pr= obably covers the vast majority of use cases for time in CBOR protocols. I=92ve updated the PR so floati= ng point is no longer removed, but still discourage its use unless greater = than 1 second precision is needed. The interop problems I see with floating= point are: - Small CPUs like ARM Cortex M0 and ATmega16/32U4 do not support it - Floating-point is extra work for a CBOR implementor (It was for me anywa= y) There should be as few choices for the implementor as possible and those th= ere are should be clear. So the choices in the PR are mostly a) 64 or 32-bit integer support, b) support n= egative time (to sort your Jimi Hendrix albums), c) support double if you n= eed microsecond time. I do think there should be clear requirements for each tag, maybe even cano= nicalization requirements per tag, especially for a tag that will be widely= implemented and used like tag 1 and especially for something as problemati= c as time. You=92ll probably say I have way too much time on my hands, but there=92s a= tag 1 implementor FAQ below. LL Tag 1 Implementator=92s FAQ [cid:76EE6EA1-F82D-4532-955E-A0C188AEE9D3@attlocal.net] Q: I just want to implement the minimum, what should I do? A: You should support 64-bit unsigned encoding. This will cover just about = every use case because it works from 1970 until over 500 billion years in t= he future and 1 second resolution is enough for most human activity. Note t= hat time values up to 2106 will be encoded as 32-bit integers even though 6= 4-bit integers are supported because only 32-bits are needed to count secon= ds up to the year 2106. Q: I=92m implementing on an 8-bit CPU and 64-bit integers are really a prob= lem. A: You can support just 32-bit integers in that case, but they will stop wo= rking in 2106. Q: Why 2106 and not 2038? A: Because CBOR encodes positive and negative integers with different major= types and thus is able to use the full 32-bits for positive integers. Q: What if I need time values before 1970? A: Implement 64 or 32-bit negative time values, but note that there is no c= lear standard for this as POSIX and UTC time are not defined for this time = period. If your implementation assumes every days is 86,400 seconds and fol= low the rules for leap years, you should have accuracy to within hours, if = not minutes. Q: Is Tag 1 better than Tag 0 for time values? A: In a lot of ways it is, because it is just a simple integer. It takes up= a lot less space. It is a lot simpler to parse. Most OS=92s have the abili= ty to turn POSIX time into a structure of month, day, year, hour, minute an= d second. Note however that POSIX time has a discontinuity of about once ev= ery year for leap second adjustment. Q: What is a leap second? A: It actually takes the earth about 1 year and 1 second to revolve around = the sun, so 1 extra second has to be added almost every year. UTC Time hand= les this by counting the seconds from 0-60 (not 0-59) in the last minute of= the year. This standard uses POSIX time which can be said to handle this b= y the clock stopping for 1 second in the last minute of the year. Q: Do I have to implement floating point time? A: No. There are not many use cases that need it. However for maximal inter= operability, it is good to support it. Q: When should I use floating point? A: Only if you need time resolution greater than one second. There is no be= nefit otherwise. 64-bit time can represent time +/-500 billion years in the= same number of bits, so floating point time is unnecessary for very large = times scales. Q: What resolution to I get with floating point? A: It varies over the years. For 1970 to 1971 you get almost nanosecond acc= uracy. For the current century, 2000-2099, you get microsecond accuracy. 2= 85 million years from now, it will be less than a second and the 64-bit uns= igned representation will have more resolution. This is because a double on= ly has 52 bits of resolution. Q: Should I implement single or double floating point? A: If you are going to use floating point you should always implement doubl= e. Single has no advantage over 32-bit integers. It provides less range and= less precision. It has only 23 bits of resolution. It is of course good to= support decoding of single in case some one sends you one, but there no po= int to ever sending a tag 1 encoded time value as a single. Q: Can I disallow floating point time in the definition of my protocol? A: Yes. This is a good idea if you do not need resolution less than one sec= ond. It will make implementations simpler and more compact. Note that while= most CPUs do support IEEE 754 floating point, particularly small ones do n= ot. Q: What I=92m transmitting thousands of time stamps and space is a problem? A: If you want to maintain 1 second resolution, there is really no more com= pact way to transmit time than tag 1 32-bit or 64-bit integer. If you wish = reduce resolution, use a different time, perhaps one that counts days rathe= r than seconds. On Jul 2, 2018, at 12:10 PM, Carsten Bormann > wrote: Hi Laurence, the representation of time is indeed one of those eternal issues in represe= ntation formats. Tag 1 is relatively well-defined as it is, and I don=92t think we want to c= hange that. Instead, new tags have been defined for time (and there, of course, also ha= s been tag 0). Not all tags need to be defined in the CBOR base document. In particular, in this round we are aiming to collect the stable parts of C= BOR, as opposed to putting in more bells and whistles. We are *not* defining a new version of CBOR (there are no versions in CBOR)= . New bells and whistles can be added by just registering tags. The set of registered tags can at any time be examined at: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml Looking for =93time=94, we see (apart from 0 and 1): 1001 map extended time [draft-bormann-cbor-time-tag-01] This tag has been registered a while ago and already has been implemented i= n some environments that care about precise time (e.g., Haskell with its pi= cosecond-based time). On to the specific changes that you propose: =97 getting rid of floating point time =97 I would expect that is in active= use, but I haven=92t done a survey. It definitely is allowed by RFC 8392 (= which uses Tag 1 in an indirect way). Floating point time has the weird pr= operty that its resolution gets lower the further away you get from the epo= ch. But otherwise, it is fine. Currently, of the 53 bits of resolution of= a binary64, 31 bits are taken for the integer part, so 22 bits remain for = the fractional part. That will change to 32+21 in 2038 =97 a date that mos= t people who work with Posix times are aware of, as the integer time_t no l= onger will fit in a signed 32-bit int then. So I don=92t see any deadly in= teroperability problems that would stop us from continuing to support float= ing point valuess in tag 1. Any specific application can be more selective= , if desired. =97 being more explicit about negative values (int or float). Good point. - requiring support for =93positive=94 (I think you mean unsigned) integer = values. Just as an application can rule out floats in its usage of Tag 1, = it could do so for integers. A generic CBOR implementation that doesn=92t = support integer values here could be considered not so bright, though. (CB= OR is more about interoperability than about conformance, anyway.) =97 comments about serialization (encoding). I don=92t think a Tag should = define that level of requirement. If an application wants to use minimal-s= ize encoding, so be it, but that=92s none of the business of a Tag. So, in summary, I=92d say let=92s pick a good way to handle negative number= s (being aware that there is no really good way). Probably MJD-based inter= pretations. But let=92s talk to astronomers here=85 Gr=FC=DFe, Carsten On Jul 2, 2018, at 20:29, Laurence Lundblade wrote: I think that the more we can reduce implementation / encoding options and v= ariability in CBOR the better. Seems this is also what a lot of the drive f= or canonicalization is about. Here is a PR for new text for epoch time (tag 1). I don=92t know what the philosophy is for compatibility with RFC 7049. This= proposal breaks it. Maybe it should be a different tag value or such becau= se of that. The big break is disallowing floating point values because you can do bette= r in a number of ways by defining a new tag for time expressed in micro or = nano seconds from the epoch in a 64-bit integer (perhaps as suggested here)= . The general decoder implementor and protocol designer is left with only two= choices: - Support 64-bit time values or not - Support negative time values or not The protocol designer should of course make a call on these choices so ther= e aren=92t interop problems. There=92s more detailed rationale in the PR comments. I=92m curious what you think. :-) LL _______________________________________________ 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 --_000_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Laurence

I don't see why you need to talk about the unsigned width. It's encoded as = a CBOR unsigned number (major type 0) and therefore uses as many bits as ne= cessary. That is, it has needed 32 bits to encode since the second day of t= he epoch and will continue to need only that much until 2106. If someone wishes to represent dates beyond tha= t, they'll need 64-bit width. But if someone wishes to encode only the epoc= h itself, they need only 1 byte.

Similarly for negative: any date prior to 1970 will require negative number= s.

So if you want to implement the minimum, you implement CBOR unsigned and ne= gative, of all widths. Any implementation not supporting 64-bit width integ= ers is not compliant. They may be able to get away with it, but if they fai= l to parse wider data, the bug is in them, not the sender.

PS: double has 53 bits of resolution, not 52.
From: CBOR [cbor-bounces@ietf.org] on beh= alf of Laurence Lundblade [lgl@island-resort.com]
Sent: Thursday, July 05, 2018 14:23
To: Carsten Bormann
Cc: cbor@ietf.org
Subject: Re: [Cbor] PR for improving epoch time (tag 1)

Hi Carsten,

I=92m definitely after tightening up tag 1 here (and explor= ing as an example around canonicalization, variation and options in CBOR). =  I=92m not a time geek, nor do I have any use cases other than tag 1. = I think tag 1 time probably covers the vast majority of use cases for time in CBOR protocols.

I=92ve updated the PR so floating po= int is no longer removed, but still discourage its use unless greater than = 1 second precision is needed. The interop problems I see with floating point are:
 - Small CPUs like ARM Cortex M0 and ATmega16/32U4 do = not support it
 - Floating-point is extra work for a CBOR implementor= (It was for me anyway)

There should be as few choices for the implementor as possi= ble and those there are should be clear. So the choices in the PR are mostly a) 64 or 32-bit integer support, b) support negative time (to sort your Jimi Hendrix albums), c) support do= uble if you need microsecond time.

I do think there should be clear requirements for each tag,= maybe even canonicalization requirements per tag, especially for a tag tha= t will be widely implemented and used like tag 1 and especially for somethi= ng as problematic as time.

You=92ll probably say I have way too much time on my hands,= but there=92s a tag 1 implementor FAQ below.

LL



Tag 1 Implementator= =92s FAQ



Q: I just want to implement the minimum, what s= hould I do?
A: You should support 64-bit unsigned encoding.= This will cover just about every use case because it works from 1970 until= over 500 billion years in the future and 1 second resolution is enough for= most human activity. Note that time values up to 2106 will be encoded as 32-bit integers even though 64-bit in= tegers are supported because only 32-bits are needed to count seconds up to= the year 2106.

Q: I=92m implementing on an 8-bit CPU and 64-bi= t integers are really a problem.
A: You can support just 32-bit integers in that= case, but they will stop working in 2106.

Q: Why 2106 and not 2038? 
A: Because CBOR encodes positive and negative i= ntegers with different major types and thus is able to use the full 32-bits= for positive integers.

Q: What if I need time values before 1970? = ;
A: Implement 64 or 32-bit negative time values,= but note that there is no clear standard for this as POSIX and UTC time ar= e not defined for this time period. If your implementation assumes every da= ys is 86,400 seconds and follow the rules for leap years, you should have accuracy to within hours, if not min= utes.

Q: Is Tag 1 better than Tag 0 for time values?<= /span>
A: In a lot of ways it is, because it is just a= simple integer. It takes up a lot less space. It is a lot simpler to parse= . Most OS=92s have the ability to turn POSIX time into a structure of month= , day, year, hour, minute and second. Note however that POSIX time has a discontinuity of about once every year = for leap second adjustment.

Q: What is a leap second?
A: It actually takes the earth about 1 year and= 1 second to revolve around the sun, so 1 extra second has to be added almo= st every year. UTC Time handles this by counting the seconds from 0-60 (not= 0-59) in the last minute of the year. This standard uses POSIX time which can be said to handle this by the cloc= k stopping for 1 second in the last minute of the year. 

Q: Do I have to implement floating point time?<= /span>
A: No. There are not many use cases that need i= t. However for maximal interoperability, it is good to support it.

Q: When should I use floating point?
A: Only if you need time resolution greater tha= n one second. There is no benefit otherwise. 64-bit time can represent time= +/-500 billion years in the same number of bits, so floating point tim= e is unnecessary for very large times scales.

Q: What resolution to I get with floating point= ?
A: It varies over the years. For 1970 to 1971 y= ou get almost nanosecond accuracy. For the current century, 2000-2099, you = get microsecond accuracy.  285 million years from now, it will be less= than a second and the 64-bit unsigned representation will have more resolution. This is because a double only has 52 bits of re= solution.

Q: Should I implement single or double floating= point?
A: If you are going to use floating point you s= hould always implement double. Single has no advantage over 32-bit integers= . It provides less range and less precision. It has only 23 bits of resolut= ion. It is of course good to support decoding of single in case some one sends you one, but there no point to e= ver sending a tag 1 encoded time value as a single.

Q: Can I disallow floating point time in the de= finition of my protocol?
A: Yes. This is a good idea if you do not need = resolution less than one second. It will make implementations simpler and m= ore compact. Note that while most CPUs do support IEEE 754 floating point, = particularly small ones do not.

Q: What I=92m transmitting thousands of time st= amps and space is a problem?
A: If you want to maintain 1 second resolution,= there is really no more compact way to transmit time than tag 1 32-bit or = 64-bit integer. If you wish reduce resolution, use a different time, perhap= s one that counts days rather than seconds. 
 






On Jul 2, 2018, at 12:10 PM, Carsten Bormann <cabo@tzi.org> wro= te:

Hi Laurence,

the representation of time is indeed one of those eternal issues in represe= ntation formats.

Tag 1 is relatively well-defined as it is, and I don=92t think we want to c= hange that.
Instead, new tags have been defined for time (and there, of course, also ha= s been tag 0).

Not all tags need to be defined in the CBOR base document.
In particular, in this round we are aiming to collect the stable parts of C= BOR, as opposed to putting in more bells and whistles.
We are *not* defining a new version of CBOR (there are no versions in CBOR)= .

New bells and whistles can be added by just registering tags.
The set of registered tags can at any time be examined at:

https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

Looking for =93time=94, we see (apart from 0 and 1):

1001 map extended time [draft-bormann-cbor-time-tag-01]

This tag has been registered a while ago and already has been implemented i= n some environments that care about precise time (e.g., Haskell with its pi= cosecond-based time).

On to the specific changes that you propose:

=97 getting rid of floating point time =97 I would expect that is in active= use, but I haven=92t done a survey. It definitely is allowed by RFC 8392 (= which uses Tag 1 in an indirect way).  Floating point time has the wei= rd property that its resolution gets lower the further away you get from the epoch.  But otherwise, it is fine. =  Currently, of the 53 bits of resolution of a binary64, 31 bits are ta= ken for the integer part, so 22 bits remain for the fractional part.  = That will change to 32+21 in 2038 =97 a date that most people who work with Posix times are aware of, as the integer time_t = no longer will fit in a signed 32-bit int then.  So I don=92t see any = deadly interoperability problems that would stop us from continuing to supp= ort floating point valuess in tag 1.  Any specific application can be more selective, if desired.

=97 being more explicit about negative values (int or float).  Good po= int.

- requiring support for =93positive=94 (I think you mean unsigned) integer = values.  Just as an application can rule out floats in its usage of Ta= g 1, it could do so for integers.  A generic CBOR implementation that = doesn=92t support integer values here could be considered not so bright, though.  (CBOR is more about interoperability than abo= ut conformance, anyway.)

=97 comments about serialization (encoding).  I don=92t think a Tag sh= ould define that level of requirement.  If an application wants to use= minimal-size encoding, so be it, but that=92s none of the business of a Ta= g.

So, in summary, I=92d say let=92s pick a good way to handle negative number= s (being aware that there is no really good way).  Probably MJD-based = interpretations.  But let=92s talk to astronomers here=85

Gr=FC=DFe, Carsten


On Jul 2, 2018, at 20:29, Laurence Lun= dblade <lgl@island-resort.com> wrote:

I think that the more we can reduce implementation / encoding options and v= ariability in CBOR the better. Seems this is also what a lot of the drive f= or canonicalization is about.

Here is a PR for new text for epoch time (tag 1).  

I don=92t know what the philosophy is for compatibility with RFC 7049. This= proposal breaks it. Maybe it should be a different tag value or such becau= se of that.

The big break is disallowing floating point values because you can do bette= r in a number of ways by defining a new tag for time expressed in micro or = nano seconds from the epoch in a 64-bit integer (perhaps as suggested here)= .

The general decoder implementor and protocol designer is left with only two= choices:
  - Support 64-bit time values or not
  - Support negative time values or not

The protocol designer should of course make a call on these choices so ther= e aren=92t interop problems.

There=92s more detailed rationale in the PR comments.

I=92m curious what you think. :-)

LL


_______________________________________________
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

--_000_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_-- --_004_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_ Content-Type: image/png; name="PastedGraphic-2.png" Content-Description: PastedGraphic-2.png Content-Disposition: inline; filename="PastedGraphic-2.png"; size=42486; creation-date="Thu, 05 Jul 2018 21:23:47 GMT"; modification-date="Thu, 05 Jul 2018 21:23:47 GMT" Content-ID: <76EE6EA1-F82D-4532-955E-A0C188AEE9D3@attlocal.net> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAp8AAADsCAYAAAAywc1OAAABfGlDQ1BJQ0MgUHJvZmlsZQAAKJFj YGAqSSwoyGFhYGDIzSspCnJ3UoiIjFJgv8PAzcDDIMRgxSCemFxc4BgQ4MOAE3y7xsAIoi/rgsxK 8/x506a1fP4WNq+ZclYlOrj1gQF3SmpxMgMDIweQnZxSnJwLZOcA2TrJBUUlQPYMIFu3vKQAxD4B ZIsUAR0IZN8BsdMh7A8gdhKYzcQCVhMS5AxkSwDZAkkQtgaInQ5hW4DYyRmJKUC2B8guiBvAgNPD RcHcwFLXkYC7SQa5OaUwO0ChxZOaFxoMcgcQyzB4MLgwKDCYMxgwWDLoMjiWpFaUgBQ65xdUFmWm Z5QoOAJDNlXBOT+3oLQktUhHwTMvWU9HwcjA0ACkDhRnEKM/B4FNZxQ7jxDLX8jAYKnMwMDcgxBL msbAsH0PA4PEKYSYyjwGBn5rBoZt5woSixLhDmf8xkKIX5xmbARh8zgxMLDe+///sxoDA/skBoa/ E////73o//+/i4H2A+PsQA4AJHdp4IxrEg8AAAFiaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8 eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQu MCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1y ZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAg ICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAg ICAgPGV4aWY6VXNlckNvbW1lbnQ+U2NyZWVuc2hvdDwvZXhpZjpVc2VyQ29tbWVudD4KICAgICAg PC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+Cm7M3i4AAEAASURB VHgB7J0FfBTXE8cHQoI7JLhrKe7uLkWKtUApUpz+geJQrLgXKxR3d3d3l+KuwR1CgP7n9y677F1O k0saYIYPub3dZ/u93bvZ90bC/ctCIkJACAgBISAEhIAQEAJCIBQIhA+FPqQLISAEhIAQEAJCQAgI ASGgCIjyKReCEBACQkAICAEhIASEQKgREOUz1FBLR0JACAgBISAEhIAQEAKifMo1IASEgBAQAkJA CAgBIRBqBCJY9nTi0lM6e+2F5W55LwSEwBdCIGOK6OpM5D7/Qj5QOQ2XCdQsloQWbb/lcj2pIASE QNAIFMoaj5LEj6xXDqR87jr5iOZvvKYXkA0hIAS+LAJ1yqRQJyT3+Zf1ucrZOE+gWpHENHbxBecr SEkhIASCRSBR/EhmyqcsuwcLp1QWAkJACAgBISAEhIAQcIWAKJ+u0JKyQkAICAEhIASEgBAQAsEi IMpnsPBJZSEgBISAEBACQkAICAFXCIjy6QotKSsEhIAQEAJCQAgIASEQLAKifAYLn1QWAkJACAgB ISAEhIAQcIWAKJ+u0JKyQkAIfHEEokX2pFSJo1OkiIGCf/zn5+oVwYPSJYtB8WNH+s/HIgMQAu4k IPedO2l+fm2J8vn5fWYyYiEQagSiRo5AlQsnpipFklAEj3Ch1m9odtS2Vjqa2TMP/Vg2eWh261Rf xXJ609RuuWlQiyxOlXdUKHu6ODSnT37qVP8bR0W/+uN5MsWlkrkTUMGs8W0+mMSO7kXFciZQ5b5J GVMxE8bOXTpf033Xu2lmmt07P2VIYbpGnCP0ZZcKe4/6XzZvOTsh8NkQKJAlPnX8IT3FjxVRjXnH 0fv07OW7z2b8zg40XIBOrb06Wy80yoULGJSrY8OPXCFWms5ceUr7Tj3Uh5omaTRK7hOFInrKvIMO xcpGmqQxaESbbPqR3ScfUpfxJ/T32saoX7NT6iTR1Fu/dx+pZNttJIw1OvZftWtae7VfOnSPuvO+ C8/fLwX4QSZKJA9KxvfeuWvPQvdkwmhvonyG0Q9GhiUE/ksCDSuloiaVUpKf/8f/chjSdxAJ5P0m LjUsn5y2HY1spnyu3n2Hbt5/Tbd8Xwex5a+jWpSIHupE3777QFBECmaOq0wfHjx5qwP4NlUspXg+ e+lPMaN5kpen6SlGGOuIvroNa/fdx3+Jmg09QvFiedGJ80+/Oia2TliUT1tkZL8Q+IoJ4Md06ppr dOTcYxrXIYdTJJInjErFsvvwl2xEuvfoLW08eJeMP9Y50sehLGljUdRIEejy7Ze09ZAvvXv/wazt 3DxDkJl/1KPxLMGxS89o93Ff+pe/vCEZeTYvS9rYlDBuRLrz8A0dOvuErt7+lAq4dJ6EFCWyB63Y cYvyfhuPcqSPTU9e+NNmHsfDp36mRvhvmiQxqGCWeOTJs3/beTbXkSSMF5mK8Hkd/OcRQSkpk9eH 9vBM2MEzj1RVR+fliIuj87IcX7l8iSh61Ai08cA9fSY6S5rYlJGXffF5xYnhSZkCloATczq7qkWT 0I17r+no+ceqHmZfYEJxi5VQTRyNwVm2WntfyiuUzyOsMJRk8wcswRuzgpXLn1Cd5qbDvvQ9p+vU BJ+NNcax1BK9DyVPEIUePX2n7o/7j9+SxnbdnrtUq1QyisX33qTll9W9EZntkItk96aUiaLSB9Zi rt15RduP3CP/DwE3BXfq6PpydH3aGpd2PvauDeO98ezFOyqey4cSxIlEJy494Xv3gdaEeg3N+86T r+8SuRNSOp7phxzn75Jdx3zVNv44w1UvzBtJvKOw+YU3Xb/3kvYHrCRE9PKgSoUS04cPH2nFzluU mx/4bN13Kfm7MW5ML7p88yU9fv7pO88eW/SvXRuOvtOMY/1ctkX5/Fw+KRmnEAhFAqPnn1e9peXl R2cEyt6wVlnULNHrtx/UElOqJFGp35TTqnqHHzNStcKJWJH8lzAT4MFrUT+USkothh2hV2/eqzI9 GmaicvkS6N3VKpmUhsz1pJX8xd7q+3RUl8sbBT/GIxdepOXbb6rdzaulIh92zEnPDjpVCpoUAxyo WzIJ/djnAL187U8FWOns/0tm8oxgWnauXzoZPXJgSgDFrk2N1LQvQ2zKwwqtR4RwPMvloZRPR+fl iIsz52U8Z2y3rZmGYkT1pAs3XtCJiyYziMqFElF5Zjd9nQdlSxOLsrGSD0mXNDr9Vjc97eEfTCif sEds+31aunDzha4cODMGZ9iqDr/AP5sP31fKZwV+6NCUTygeZXL70DteGdh25L6Z8mmNMZSMoa2z sGLppRPC9Vzxt52ksc3PD16F+PqELNp2kx90ItCQllkoYTxzZ7N6ZZNR25HH1IOHo+vL0fVpb1wY h6NrQ7s3dqeNSd+kiMEPPqbzw7mNXXpZ5xWa991bvw80sl1Ovg9iqpWbCDxzXZu/S+r0eqFm/FMm iu6QK87dKDkzxlHfAUcvPNWVz7gxI1K7WmlVsbV771KDcils3net+PsD3023H7ymvSdND8KO2KJh 7dqw951mHOfntC3K5+f0aclYhUAYJVCjaFKleA6YeY7W7r1N3jz7kSR+FDVa/EBC8bzGs29thh8h D56V6PlzJsrJilytUslp2qrLVJhnFqF4wm5u2tprPKv5mMrmM/24w/EDP2Y41n/mWbp48zlVLJiY 6pVJxj8IaWjPiQdmM6wV8yagiSuu0BNWKtuxMxF+JDAjs2bXLWrDSiwUz/3/PKZFW29SWS4LJcIk 9h2q8meKQzd4uXrF7rt0l2denTkve1ycOa+gfNxjl1yiuqxUY7bun2vPae6mm2aznMY2nRmDcfba FttV/IDwpcqB0w8JD1SpEkdje84YdImvv8LZvNUD1jaeOX/+2vTwZOv8YfPXqV4GpXhiBm7a6isU LYqnmcKKulA8F2+/pdp7yrOIfZpkUornrhMPaRJfzzGjReD75htKzeP4qWIK+nPBBbJ3fTm6Pmes vmx3XM5cG9o5Y+wnrzyjUfwwWC5vQiqQOQ7fn0mV8onzD837DjbOUDxvPXhDDfih8+O/HylPpnj0 5LnpQa1z/fQOuWrn5cqr3Heu0CISq3PXeElpISAErBB4/8G0lFQ6j48KW4TlRMy0QUrmNCl3m3l5 8j3PVsKOdCf/oEKypDZ5fxbNHl+938dL2bPXX6Xz15+pH9f1++6wUmqaxVyz/x5tPXyPbrICOGnZ RXr0zE85zmTlpXijjFx8kWatu0qrd92mfadNS+OJ4rIy7BOVknpHVkUHzzpLUCr68szs4XNPjNVt br94488zTkdpwaZrtJOX8Jw5L3tcXD0vmwOzOACHhiu3X6m9vvw5YJkWCpM1cXUMtthaa/tL2ffO /wPtCFhCLsvXN6RSAdM1ueHgPYenmYgfwtIGOCWNmHdemUbsOOpLbUYcMas7a+MNGsUrDlNXXibv 2BHp2wDTiWFzz9HVOy/o+IUnPLN9XdUpxA90EHvXl6Pr09G4XLk2fNkWtt2oY+r+/Gv5JTU2zPJi eTu077v3700mCd5s/lOWPycPj/A82/hArbAkZZMTZ7iqE3Dxj9x3rgGTmU/XeElpISAErBCYwT+K 2dPHoty8NI2wRccvPqVBs8+qZa5kCUwKHxyY8N8o0aOYvoKSBSiFJy8HNsjXFMYrd17qVbF0f8P3 jZrVxHKWUe4/fqO/fcw2n5BIbKuplXvxyt9spvSBbg/6yY5Ob8CwcffhWzPbUWfOyx4XZ87rISvY ISnOjMHYvy22xjJf4jYenGDWgJnyZTtv86x9LMLDCB5gkviY7AptnXcitruFvOHl4GusRNqSU2wn qQkUQwj6wEOWJjfvmR4qfPhhCl7i9q4vR9eno3E5c21o1yecrvzYPhZijIgR0St8qN93l249p/UH fakcPyh05mgdrdkcZ8b6GzR3wzVylqvGO6RenWFr7PtLvO9E+TR+wrItBIRAkAhgprLu7/upSqEk VKNYImX7NLRVNt63l969Myl1K9mhYn/ATKTWyQ024Id8hDbJEi5c4MWYd/6mYxHZztIokdkpCfLs tXPhn94HOGl4sb0efrg1RyZjm65sO3NedrkE8by0cXvyjE5wxV1sgzuOsF7/6NlHhIcW2DT24KVv eMBvOfyA/ANm2eyN/2OAf0l4Xn8OuMztFVfH/AOiTETkJANGwUMU5Dkre7gO7F5fDu67eDFND222 xuWua+O/uO/+mHqaNuy7SzWKJ1HmDC2rpab7T/zocYAi74irkTm2tXvOi+293SHuYuuOsfxXbQT/ 2+u/Grn0KwSEQJgh4MlfyrBTm7nuCv0yxLSciKd72LZdD/CqxiwIlquN/6/dNc3kXGd7UEjR7PEo fMC3EuKLIl7l9YCwQIWzxFVKI8rBy1ZbyrzEHqTOyJ1HphlRxLjMlSGuqoJ28mQ0X7Z3pi2Ucea8 7HIJ4nk9YcUDki55dPWaLEFUyvtNHLWt/fFnD1xI3IAYrdp+y1d3sbVs90t7D+/yLUdN3ttZUplM RTY5seQODrfYyQSC6w52lJrAztmWaHW8uE7ODJ8+2yJsawo5e910zdu9vhzcd1oftsblrmsjtO87 ODPi4fIQPzAgNusqdgaCpE8WXf8sHHFVFQx/oOxDEMVAy4RWwxDhQCsq951GwvGrzHw6ZiQlhMBX RwAhX4oGOFVoJz+0dVY10zOEl9OvByz/acf+6pSbrnAYmDPs4JKRv+Qhd9jgHx7mS7beoO/Y+7ws O/ZE5h/Tf669oKi83J4zXSxax+GClrFn71J2tKjI9ln4YZ/WPS+HUnrLCmJsmrf5Ji3acpMq5U+g ZlMndMxFl9ieEYoofmTgxe1s0GZfVj7hrZqD++3fLDMdu/hEOSZE8tS+Bl2b1XDmvOxxcea8krNi aSknLz+jFByup9l3qahI1njqR1WbmeG5Y1X8NrOHgOeY9jmVd/uYRRfUPuMfZ8ZgLP81b2/lpfeq 7DgHuc+mGicNy+T2uNzj6w5B6uGUM4CvO4QIgw0ygtMXb2U91BdspjezF30pdhob0Oxb2nrsIcVj xzk4vUGmrrmiXu1dX85cn/bG5cy1Ye36VAMz/Ant++4h2582r5aGQ5H50su37/WHy/McHcJZrobh q82z15+r1RlEmZjVM6+yXU8SPxJ/H35UDoxQdiFy35k4OPNXZj6doSRlhMBXRiCpd1TKyh6j2uwi Th+hVLAvKudCt5SD7LRThm2sfquTTimRF2+9pG4TT6timN3sNOGkUkaLZItPzaumovrsqY64d1e4 HOT8jef0++QzbC/mr7x5C7NSBVtMeLLD2aLj+JPsYf6WvmVlCgoAZlSX7bxDvbmOJvCGh2jL4aZt 05qndqwfL8ed4x8hZBsp8G1cVkCfUX92PoJoS53qjeEPwulAtFftkDPnZY+LM+el9am9ou+pHB0A P6RQvvGZwHlr4OxzaljaOew5cV959GNndla2o3CaVIjWjvbqzBhQT+Nnjy3KfSnyjpUKiDHJwvGL j9U1iP2r2YREU/j9OVYtQoi91a4/K9fLIL7GdvK1jFlGXNvJ+OFhMcejxYyqNbboYyg/5MFUBQ9H lfnBTIu2gDBL2gOXvevLmevT3ricuTa060h7xbixzI4waNp/7AvN++4qPwR7sUlK0yopVSgkOD7N 2nBdxfvFWJzhqp2P9goFetSii/SBzSwQ+gpxiDvzdxoeuLHv40fT9WLrvrP8jJ1hi7Fa1sO+dwG2 tdox7PscJRzfNCaDqoDRG2NzfY4nJGMWAkLAPoE6ZVKoAlrMQvulnT+K5Sgf9tJ9waFnHj//5CRh bCE6zxzE4WDb9srED3AgMob40drAzAPyzePHwNJ+jnUxFcbJ0g4PMTnhsWyUODEismLxQY8xaq2M sbwX2975s0e/+bflpxL2zssZLvbOy1bfCOYPJxYtTirKWQbtRwBxxKQEL01stWdvDK6w1foJy69b /iyuUmHaGyMClUOBMl5nmOHyBGeL6wlB+z/yxRGgg5AtxvgsYE6CByvNQccWW21seMjwiRtZ2Xm+ ZAckS3Hm+rJ3faI9a+My9mPv2rB2ruAB0ew9tbZC875DuDcvDqsGW0/LzwvjccTV2nlhXxx+aMZs NgQmQuH5orA8T8v7zt5nbI+trXqOvq/U4MLYnwEtsvBKTXx9VNp6k75DNoSAEBACQSHw1u89L8fb j3kIpw38tyfWlE6t/HOui//WBErCRysOINZ+eCyVY2tljH1YKnXGY9i2d17OcLF3Xrb6NmZtwhis lYMdrqVYK4cy9sbgClvL/j7X98YsQto54OHD2rViqXzYYgyF05hZCu3aYqv1CQX4ToDdqLbP+OrM 9WXv+kRb1sZl7MPetWHtXC15aG2F5n2HJXZ74oirtfPCPk3xRNt42PhIZvN3qkvL+87eZ2yPra16 1q5Be+caFo/JsntY/FRkTEJACAgBISAEhIAQ+EIJiPL5hX6wclpCQAgIASEgBISAEAiLBET5DIuf ioxJCAgBISAEhIAQEAJfKAFRPr/QD1ZOSwgIASEgBISAEBACYZGAKJ9h8VORMQkBISAEhIAQEAJC 4AslECjU0gd239LCRXyh5yynJQS+agIIMQKBt6eIEPgaCSAUkC2P7K+Rh5yzEAhpAh58zyEslSaB lE/tgLwKASEgBISAEBACQkAICAF3EwgU5xOR+v81Bet3d1/SnhAQAmGAQLiAmc9/ZeYzDHwaMoT/ gkB4BIXnTDwiQkAIhA4B3HPhDDOfgZTP276v6C7/FxECQuDLJJDQx5QvXO7zL/PzlbNyTCBXFh86 ctp6XnXHtaWEEBACrhJIlzIWxYoZSa8mDkc6CtkQAkJACAgBISAEhIAQCGkConyGNGFpXwgIASEg BISAEBACQkAnIMqnjkI2hIAQEAJCQAgIASEgBEKagCifIU1Y2hcCQkAICAEhIASEgBDQCYjyqaOQ jS+NgP97fzpyeA+9fvXiSzs1OR8hIASEgBAQAp8tgUDe7o7O5J7vHdqzc6MqBrf5aNFiUK48hSlO nHiOqobZ4+fOnaQTxw5SzTqNzYKgYsCbN66kSJEjU6HCpcPs+G0N7O6927R31yZbh1XYg0qV69Dy ZbPp0cP71KJ1V5tlQ/LArZvXaPu2tfTwgS8lTZqCSpWtSjFjxg52lzeuXaaWTb+ngUP/phKlKgW7 PWlACAgBISAEhIAQCD4Bl5XPZYtn0vTJoylBgkT08d9/6emTx5wR6QM1bNyWmjbvGPwRubGFG9cv 04plc6hhk/9RdFaSbcnWTatpxtQxVO37BuTl6WVWbPrkURSLFevPUfk8e/oYTZ44XD+fJ48fkZdX JIoazRRqJ3y48Oq8tm1ZQw987/4nyueGdUvpj97t+eElLsWL70NrVy+iaVNG0+oNx/Vxy4YQEAJC QAgIASHw5RBwWfn8NyD35qKV+5SiBoWmR5dfWMkZQQV5dvCbTNnCDJ1z507R7BkTqPJ3de0qn2Fm wG4eCGb7jDN+VSvmpvQZM9PgYVPNeho3aYl6gDDbGUpvxozsQ1my5qTRExZQBI8I5Of3ltatWRRK vUs3QkAICAEhIASEQGgTcFn5tBxgbJ6xqlu/OR0+tJfOnjmmK5/v/Pxo+/Z1dOXSOUqYMAkVLFKa 4sXzMat+5tRROsw2ef7v/Ch/wZKU6dvs+nFH9Q8d2KnKZs2Rj7ZvXUvXrlygzFlzU/4CxdV+2Pod ObhbbW/dvJrixo1P2bhs8hRp9D5c3Xj+4hmtX7OYSpauzO1569U3bVjBs3belD1HfrVPG1uWbHlo y6aVdP36FcqbrwjlyFmA82l/pA1rF9MN3oex589fTG8HGxj3saP7yd/fn1KlSkcly1RRShmOwXZx Dc8MVqxUk+7xTOXO7espSpSoSsG0ZIvyzsrRQ7vpxcsXVLxEBVUlOON39LkZx4TzefDgPp/jd/o5 RowYiapWr28sRq9fv6Ktm1fRzRtXKWGiJFSmXHV13ihkj5dZI4Y3ly6epYMHdtCb16/5mslFefIW MRyVTSEgBISAEBACQiAkCQRb+cTgHj64p8bow0omBHahHdr8SM+fPaXUaTPSovnTaOKEITRkxHT6 NnMOVWbMqH40Z+YESpU6HYUPH17NnPboPYIqVanjVP2F86eo9t+zU8m9u7cpcuQoNGXSSGrU9H/U rGVn2swK4Z7dm1Vfq5bPIw8PD/KIECFYyuf1q5do+OAelDhxcp7lLaXaxp9JEwZT+gxZdOVTG5sf K9WwpYTAVKFz90G0cf1yVpQvsq1sdJrG+1q17UYNfm6jynT5rTEd2L+T0qfPROF5vHNmjKflS2fT hL+XquN3+TyHDepOsJFcsXQOJU6SjO7cuUWzpo+jabPXBVLuVSUn/iyYN5nu3rmpK59BHb8zn7tx OFGiRqdEiZOqz6pC5Vp83t8aD6ttmE78r/UP9IoV1aRJU9LtWzfUdbNo+V5yxCtQY7xj1vSxfC0O pUw8Q482J/F2uYrVqc8f46wVl31CQAgIASEgBISAmwkEWfnEbCPkMs9swg40T77CVKCQSSEbM7y3 Wj6ds3g7xYgek2fVnlOTBpVo1PDfafL01XSaZzyheP7EdqItWnVR7Rzn2b5Xr16qbUf1VSH+c5yd hKp/X58mTlvJCqwHdWhbjxbOm0qNfmnPit4Qyp6rAPXs0oJGjp1DKVKm1arZfO3fpx07HJkHAHjI yiNsPl0VjK1mnUbUrmM/NbNbr3YJGty/CxUuWppWrjtCEby82BmmOo93sq58lilfnbr1GqGYob+l i2eoOnCIysDKrSZQrCdOW6GUNcweN2pQUX0G7rS5Dcr4nf3ctPPAa8cug6hH1xbUuH4FdjSqQo2b tqekyVLpRYYP6UHvWImfs3CbUq7fvn1D82ZPVMed5aU1doVnx/8aN5jatvudav/QVO1esmg6DRnQ lRXQmoFmobV68ioEhIAQEAJCQAi4j4C5puVCu8MGdaM+PdqoGb0svHQ5atx85Sn+/sN72rFjA1Wo VEtXouDsky9/UV6WP0EIf4Ml1H/ZWalSldp6j1gSx2yiM/W1Sil4CR1KJmwFw7PnfbHi5eklK7oP 7ptmYrVyzr7e41nEu3fN/3/g8wmKYGy/de5PHjyrGylSZMrJinBU5jBw2BTyihhRjbdAwRJq2VkL BVSiZEWdGfrMmi2v6vrO7ZtmQ2j9v576LGEmnknGDCiW8d0pro7flc/NOM4ChUrQtFlrqBCbZWxY u4zqfl+Mpv49UhV55/+ODvJMMDhoZgVg+TM7kEGc5aUK8x+YTMBMoWbdJtouKl+hBnnyg8DhA7v0 fbIhBISAEBACQkAIhByBIM98rt54nOB8hOXzRfOn0tZNq6h02e/o7u0bPNP3jqZPGcOzm3/pI4cN 40cu/+bNa146vUbe3gnUMqpeIGDDmfqePJsK8fTyDKhleokeI5baeB0wg2p20Ik3YyYuCuTtXq9W CSdqBi5iObbIUaKxkhyePCN8GjMUIchbto/FEjRsSufzrN4hVoSePHlIfm/fquMfP3xQr9of2EUa Be28efPKuCvY266O/9GjBw4/d+1zsxwc7HAHsVKOmck+PVrTxPFDKE26bygJL7PjmsmaPY9lFfXe WV5a5ds3r9Hz58+odJEM2i71iuv1DduViggBISAEhIAQEAIhTyDIyieGBiWofac/6Ag7rCCkD5RP TTGq91Nzqsj2m0aJFCmSmtnDEjlsGq2JM/Wt1TPuQ/zRkBCt3Q8cWiokpG2L2vTi2RNlNpAseRqe Fb1HXX/7NEtnr09tbPbKhOQxd3xucLAaPHI6fVcuJ+3bvYXq/PiLGjLsda2Jq7w8I3pR3Hjx6W82 /bCU+PwwJCIEhIAQEAJCQAiEPIFgKZ8YHpa7q9aoTyOG9GQP4p3KczhGjJjKgSVx4mRWzyBxkhTs ob5OLXHDE14TLMl7+yQiR/W18o5ePVjJhbxkT253SOwA28/7HLxdEzjZvODZtOAKnIhgltClx2Cq WNlkjnDl8vngNhtq9YPyuWGpHiYTRokQoGjGiBWHEiVJrpbET588QjVqNtSL4TrxZecrV3klS5Za Le3jwSdhgsR6e7Lx9RHANXTy+EHKmDGLWnX4+gi4/4yvXb1IUaNGo/jeCd3fuLT4WRNAxJKrvLKV kR09oTO4U27euMI+Jn6Uhp2bbYkzZWzVlf0hQyDINp/G4VRiT+Uo/KWzZOE0tbtKtR84M9Aqghf1 w4e+9Ixn83Zzpp0Fc/9WxxHMPQIvP/fq1lI5H/1z5jj16tGKxv/Z36n6xr7tbSdMlFQdXr50FkGR wwUYHEnAinKChIkJ3uBw9IHTVSt2GvLjZVvYsAZHYsaOw0wiKKX80aP7BCejXt1bBqfJUK/r6HO3 HNDaVQupfp2S7NE/S50vHl66dWyqrqWy5aopE4UyPJuuXUv4cVuzagHV/I7tZ6PHcJlXtRoNKDo/ GP3epTmdPXtChXBCmzOmjaHr1y5ZDk/ehwECr9iGe9WKeWze05ejQ4xS14nlsGDKs3b1QlUGn+WF C2csiwR6r2W/2r9vR6Bjxh241yeMHWjcFWa2w9rYOrb7iUaP6BNm+MhAwg6BbVtWUyN2Kr1z67rb B/Unx4ruzfqDPXGmjL36csz9BMynnZxoH2GRsMRrXOaFI02RYmVo2+Z1BG/kZi06qziV8CzGjCgk VuzY+uwVZkT7DBhHIwZ3o8bsqQ1JlyET/VC/hdp2VB+FMHvlYTFrpi3PYowQBLwvVqIcrVo+X/3v 2KW/mSe1KsR/rJ2Tfgz9BLSH1y49hlLf39sqD/OYsWJTk2YdaM+uzSqUk1kdK2PTxqWVQ+gnCPbD Katt+17KG7tCqaycXjImRwP4lXx9x+gmClp97VVvh/uyZcaglcErxh8hfOCP3JKl5XtVlzkE6tcw fpRx5nNDOU0KFCpJyK40jMNXwe4SgtBbA4ZM4tf06n07NuuAE9mf/KP2/v17lc61ao0fKTbPjLrK CzFph4yYxt7tnanhD+VU+7iO06b/hkpxrFGRsEUADwTNm1RT3zWJ+Dvj9s3ryh64Y9cB+ncJyrRs WkM9SCDWru+9ezSJbYZ/43sdDxvBFcvsX85mTQtuv87UtxybM3WkjBAQAkIgLBAIxzN2ZlN2N+++ oLu+tp0vkFITQeE1Gz/tJLD/HWengTeyJtiHJx0oWT68zGltuh35xz1ZsYkXP7DNnb36WLKFM4pl OkzMgiDmp1GQhcnf308t6Rv3a9u2zgnHsTwHBcW4PIzy99grHucEhc6yjLWxIbj8e/betuQGZd3I DEHafe/f4fiXyVXbyPhjrGPt/OAVDsXQOEbt3IyvKAeFXVOmtWOW47V8j3LOjh9l7X1uOG4pYODL 1wFCWsUMcBqzVSZhwqQqWoB2PCi8UBczag84l3x8TumJh6evSRL6mBzd7N3nYYHH+fOn1dI4zHrg qAcHs/q1S6qhrVh7WL1i1WQPr6r8yIku4LR36+Y1atqwslqJWL/1tM3TQIi4H2oWp4FD/zbLAmZZ Adcy0gdr99bGDctV+LYFS3eSM+HbLNtz53vLsbmz7aC0VbNqARXv+I9BfwWleqjWyZXFhw6f9A3V Pr/mzrBi1ff3/9ESzoyYJGkKt6LAjDviVM9esNVmu86UsVlZDriFQLqUsShWzE/O0oGnwRx0AwXS qAxpxbHfqERhP/Y5utDs2d7Zq69+DKz4oVgqnhgHZrzsia1zQh2jd7rWBsonCljSt1bG2tig8HlY eKmjriUzhGFCMHVNLFlbOz9LBVyra/lqq5zleC3fox1nx4+y9j43HLcUMHCUecpWmaDwQv9QOL82 pdOSe1h/j6QDxsQDiBmclqMgHOFsappgdcOY0hffN4iOsG3LWsJDp6N7H+1AEd28cQWvzsTlFZxy KiOb1r4x+5ezWdNczYRmK0ubNoadHLrun9PH1HcF0uUmS55aHTKOTSuL7F17ObkGHlK9fRLyvRhe XeelOFMaQro5myHNmSxgyIR2gu1m8RAuKwfaJyCvIADTMWTge/zoIWcvtB0xBisXh9lhGeER8RtQ tFhZ3Qbb2ftII45JIJhy3WFFFNkSCxUpY3XCSyvvSjY+rY68uo+Ay8qn+7qWloSAEBACzhNAsorz Z0/x7FrgTFjGVl6yAyDCj0Vn0xVHsnrlfE5ne4CSs0KH9K3TOMbs8D9n66l+jdm/nM2a5momNFtZ 2jD2fr1+pV2sfCJhxrOnT2jl8rm0dNUBdVrGsWHHimVzaOjArpSN0/o+e/GULpw7Q7FZoU6RKi0r h1XYwdO5DGnOZAEbNri7CrGXPEUqdrh8TnM5RNzrV7ZXzNSA5c9XQQD+Fb+2qquuB58ECZWttpbZ 0Ahg/pxJNO7PARx20YcfEuOxL8U0+vuvoTR05AxKnSYDOXsfoU04NP38Y1mVqMbT00vFHy9Trir1 GzjB2KW+7Wo2Pr2ibLiNgFscjtw2GmlICAgBIWAggB8yKEOjR/Smn+qW5lBZPtSds4DZEpjxnDhx mPLmL6ovldsqi/2XeaZwyozVNH3Oepq9aCuF4xWKCWMGWK2ChBZt2/dWx5A1bTEvISIdcHAEmcTS 8QzvivVHaOGKvZwlroTK0oZZHJMj1WL6pUUnGjxsKv01eRlNnrHGZneT/xpGlb+rQ2MnLaZZ8zZT 2QrVydPTU9UzVtIypCFr2NgJC+i+712VIQ1ltCxgbX7tQROnrlBLmZ26DeQEDUtp377tqpnz508p xbPeTy1p4bI9tGrjMcrMyS6QDc7CikuVlz9fFwE4DiM29ZzF22juou3094xV6sEOFP7lfxBcZ4gR XrlqXVrCD1O4rmfO3aBM90YM6a7KuPIHaZdz5iqo2lq4bDfVrfeLSmWNmXlrYszGN2rsXFq+7hBF jx5LZWG0Vl72uZ+AKJ/uZyotCgEh4CYCiEawZdNqZdf58MEDtj1+ryJX2Gp+KDuTeXlFpDbteulF YOsMRU77D1tJTZq37qo7t8EECFnWjh87oGyctTIh+WovS5sXm+lEjx6dZz43KntXjCNOQLg3yzHh HO/z0qW2JI/j2XPkVftgU20UexnSnMkCtoUjmSArWMMmv6pmYabT7fcRbKduii5i7Eu2vy4C8A3Y zw8pJUpXpgQcNhGSMWNWatriNzMQq3gG38PDk1q37abvh8lMqbJVeRl+r7pX9QNObOA+QiprmHxB 6jc0eb/v3rkpUG34NDjKwhiokuxwOwFZdnc7UmlQCAgBdxGAjSP+Q+5zTN2uHZtQt06/0OSZq9WP mrGfCeMGsb3jVur9xxgyxhj+4fuiPPNyTS+KWLpZspqyZlnaVCfhGMTIxvaEbdasOUHqjbhpwzKT mDFLG+ysO3YdzEvpXahGpbxUtER5+qV5R6uOk7DnTpsuI63jFLL5ChRXy5hr2P4tLcc+tLQrtzxn Y4Y0Z7KA3ePZ5bisBCNCh1EQKs4YBcV4TLa/DgL3799V90+KFCa7ZO2ssRQO4Tg56hVZDuN7e+v2 nWon/0keUO+2iyGZLO+juHG9VcSYRxzq0VLu3nachdFWNj7LtuR90AmI8hl0dlJTCAiBUCSARAbN WnWhNs1r085t682UT8QYnj55NLXimZRyFWqYjWrU2Hn06vWnRBNJk6ZS3rFmhQLeILoEJFpACt+A 3S69aApYcDKhaW0ga1y+gsVpxZJZBBu5A/t20JxF21SmOOOgMJsLpRKzn3VqFFWHELasd/9xxmI2 t7X+nMkCFj58OBX2zGZjcuCrJeARMPP4LiB0ni0QiPONhzxLefvGNEsfM2YsFbYRx4N6H719+86q U6n28GUvC6PluOS9+wmI8ul+ptKiEBACIURAy1amZRtDN5jtQ6xYLLU1+LlNoJ7tRdy4fOmsPrOK iqfYXhSJJCxnC7VGncmapo3NXZnQMMNY76dWKjtMy6bf0+kTR5RtqDYmvF5l29jTp47RvMXbVYY4 noKkeGwf66o4kwUMs8PrHi6hmzev6pE5HnIqYHdkenN1vFI+bBGIx9mtEEXkDEdnMAqiJxglKTv4 wZwGiV+SJkulHzp6ZC9ft94qS9a7AOXUmfvo6dPHZtEtYOvp5/eGUqRMo7etbQQlG59WV17dR0CU T/exlJaEgBBwIwE4GSEea5ny1SlhomR0iTMXjeNMR7B7LF6iguoJ4Y/69+1A6TNmJnjUIuuYJojD 6SgW54xpY9UMS1meLd3NtpWHDu6mps07aE0EejVmTcNyNRx6jD+eqGDMhJbxm2wcT/aeyr7kaiY0 lUVt2zpCRjic8/6921U832TJP/1YawOMz2GVvL0T8KxwLUrOP7hQnmPGjE3Zc+aniuwUZRnbV6tn +YrA/PM5Ex2ygLXv/AdHAUijzB12cNicYsXLq3A4aG8azzL379Oe7ez60nP2wh86qKtbMr1Zjkfe f14EYHNZlBPObNqwQmWuy5m7kHJmW7FsnjoRzeGoZq2G7LQ2jXrwddbut74Ul+Mtw954145NbK9t Skzjyn2EsGotmlajlm27q+t+cP9OKtJD+Yo1rQJENr6F86ZShm+yUkm2T4VZwKmThzmRxTWq/UNT q3Vkp3sJBFn5xDLPWg4ci+lzy2UuDBGpEvHliWWsXLkLUq48hfWRn+Jc3RfYY9KaILh6frZZ0gRe cYcP7uIwI485nl92ylugmEMvVjgWIJ0X4vfF4C9gxBlLly6T1qTZKzKWbN28mspVqqkbSBsLONM/ nroQ0+zG9SsUKXJk5bQAI2sRISAEgk4A9+2oYb9zCCHTDxda+ubbbLyUPF7PH46ZSmTHOnvmBHXu 0NissyrV6lJ3doSxJvBqh3T/fbgK7zJ7xgTlRFO5ah2VWUyrY5nty5msaVD0gpMJDX0jaURMzuK1 Y9tamskKMgRZ4jp06qfHTjaODU4/mHGNGi268vrF9+4V/v4b0Pc3/q49Q7917q/aRDuBMpVxXbQF cSYLWEJOM9yr358qe12DOmXUj3yDRq3p6OG9gdpWjcqfr4oArjWk1R7cv4uKfpAlay7qxxkN27et r2clhD31sFHTaNAfnahZ42qKT5y48aj1/3pwwogW6r0r91HR4uU4+1106ty+kUo+A+e3wSOmqpBr aMx4r+C9q9n4UEfEvQRcznCE7qHU/dGnHQc+Ps52V1loOodI0ATebp3bN1RP6Rm+yUJvOP7WpYvn +GmiCbVnbzTIEI5Fh6UyS3n96iXH18tGU2etU4eWLp7BxvbdOIhxIvXFih+YQuyNOmDY5ECZjbS2 rKXb+/DBP1C6PXi8zZw6hsO4jFMxwoaOnKYCTGvt4NWZ/jdvXMlP/V2UIXVKTgmJc4Dn6TwOMSEi BMIigc8lw5HG7tmzJ7yk9lAFM7eWZEEr5+qrlj0M31m3eQkZwdI1ezCtLWvZvnDMUdY0lMEDuquZ 0FAPD8/G84SjlR9nlcOsq0oAgUIsxrEhHNVUno1cs/G4/oOLMm1b1laZvLTvI8u2UQbfV9YypDmT BexuQKY3zHhZZnpD22FVJMNRyH8yiMuLkEuYgYdo95tlzwgmjzidmne85XFH95HxusNE0Ft+8LJs y3ivGNtH246yMBrLy3bQCQQ7w9FWzsXdt2dbKl6ygkqzaTmUZYumq6nzwcOnULGApbHBHP5kwdzJ VKXqD5SGvS87dR2o/hvrIj5fzSr59RlS2IIMGdCVavD0fMcuprh769cuoV7dW9M69uL8rno9Y3V9 +xUrf1Vr1AuUbm/iuCFmuZ5/4RR8T548Iky/z5/zt15f23Cmf4SBwZJfAZ6p7TNwvP7DgJtBRAgI AfcQwI+X9gPmnhZNrWiKJmZYjCGKjH1Yy/aF485kToJC5momNLRtVDzxHjZq1sQ4NijQePDdvnUN lSr9nUpBi9SjmP3Mm7+YXt2ybRywlfnMmSxgmAXVxFo2OO2YvH59BCyjIWj3myUJZC7Df1vi6D4y XnexeLXAmhjvFeNxtG3PJtxYVrbdS8DlOJ8xYsSkMX8t5GWXMfyEHS3QaGCXlDRZCl3xRIGfGpvi wW3ZtDJQeW3H3JkT+Ok7AtWqa1o6W7l8Hi/pR2Dv1e5aEbW8nzhJMtrEs422BMtiTTkcCfI8Q7R0 e1A0MVuhSVm2I5u/ZKeaSdX2GV+d6X8eZ/WIyDEFe/YdrSueaMN4MxjblG0hIASEQEgQqFWnMRUu UpozIrWjEoXTUsnC6VWO+2w58vNS/R8h0aW0KQSEgBAIMgGXbT5zsQGxPXn+/GkgT1FMgceOHYew JG5NkHN4w7qlvOxdRvfQPMtP7fBUg1G/UVKlSq+W/Y37HG1bS7fnyKjYmf6PHd3HM7WFAp2vo/HI cSEgBISAOwnge3LY6JnKQevevTsqUxNindqabXJn39KWEBACQsBVAi7PfDrqICl7Yl6/dkWF4dDK wnYoAnuFvnr5KdaedgyvSxfPVHmL69Zrpu9++vQRaQGX9Z28ETNWbM7f+ty4y+62q+n2tMac6R+B q58/f0JtWtSiciUyUflSmal5k2qE5S4RISAEhEBoE8BSOfJip0qVThTP0IYv/QkBIeA0AZdnPh21 XJ/j0e3ZuZl+aViFsmTPTQgae/7sSXrK4TjSp88cqDpslaB8Zs6Sg52NsuvHUQ/em5aCkAiv+RgM hf0MaeMQf88rYkTL4mQt3V6gQlZ2OOofs7UfeeyX2ZkKdqM/sIfek8cPaOqkkdSBvfoWrtgTKAOI lW5klxAQAkJACAgBISAEvioCblc+EVdv1vxNypsdKbRipUxHP7PNZ89uLTlUSGBj4C0bV9DtWzeo WcvOZuARMgQG9JYCj7lYPPuJME+wb9IEhv3L1hzU3qpXW+n2zArZeOOo/wgRTOnCypSvZjb2aDzz 0LHdz7R/zzZCdhIRISAEhIAQEAJCQAgIgU8E3K58oun4nOXAmGnkMYdJecBp3zJyQFdLQco4ZBQp WaaK2SEsud+5fd1sH94g7Ag82kqWrkJp03+K3Wnp/GQv3V6gRq3scNQ/ZlmhaCL+qFGSJE2p3r54 8dS4W7aFgBAQAkJACAgBISAEmIDbbT6tUZ05bYwKH1KqbFWzw0iBdYZjhX5X7Uczb3EUysGZOTAj anRSQtyws2dPc9D4kqo9LONr/5MGKH2o6yjdHso4Ekf9o37yFKk4pd0Rs6bO/mOy94RjlIgQEAJC QAgIASEgBISAOQGXlc9n7M1+/Oh+9f/165f0hu0u1ftjB5Qd5mnOarSDU8I9uH+XFcUTNHJoT5o3 exKHW2qrZiyN3c+ZOV7lga1R+2fjbrVdvnItdQxxPZERCblhu3dqyuGXPDiOZ/1A5bUd1tLtIeUe /iMupybnz59W40bAfAiO4TwQNBniTP8VOCsSnKvGjOpHt2/foN27NtHE8UNUoPxsOfKpduSPEBAC QkAICAEhIASEwCcCLmc4wnL2EM46ZE2WrztMpzndHWwx/fzeqCLITlS/YSuqWbuRWRWk3/qufC6q VKUWde053OyY9ubokb3Uv3c7usUzoOE4GGzK1OmoB6fLy8Q5nG3J9CmjacLYQVYPG9PtfVc+JyEk iaWUq1id+vwxTu12pv9hg7tzDtvZKsWfF8f8zJuvCHX9fRjFjett2bS8FwJhgsDnluEoTECTQXxR BCTD0Rf1ccrJfAYELDMcuax8OnOO7/z86M6dG+xgFDfQbKexvrVUb8bj2jaCw0fw8vzPvMcd9Q8n KNiiJmCnJwkwr31q8hpWCYjyGVY/GRlXaBEQ5TO0SEs/QsBEwFL5DBGHIzjjwOvdkVhL9WatjjOp 7KzVc9c+R/0jkHPSZKnc1Z20IwSEgBAQAkJACAiBL5aAyzafXywJOTEhIASEgBAQAkJACAiBECcg ymeII5YOhIAQEAJCQAgIASEgBDQConxqJORVCAgBISAEhIAQEAJCIMQJiPIZ4oilAyEgBISAEBAC QkAICAGNgCifGgl5FQJCQAgIASEgBISAEAhxAqJ8hjhi6UAICAEhIASEgBAQAkJAIxAozue///6r HZNXISAEhIAQEAJCQAgIASEQbAJIFqRJoDifL16+o1ev/bXj8ioEhMAXRiBqFE91RnKff2EfrJyO 0wQSeEele/dfOV1eCgoBIRA8ArFjRaZIET30RmTZXUchG0JACAgBISAEhIAQEAIhTUCUz5AmLO0L ASEgBISAEBACQkAI6ARE+dRRyIYQEAJCQAgIASEgBIRASBMQ5TOkCUv7QkAICAEhIASEgBAQAjoB UT51FLIhBISAEBACQkAICAEhENIERPkMacLSvhAQAkJACAgBISAEhIBOIFCoJf2IjY07t2/Rpk3r 1FHEbIoeIyYVKlyM4seLb6NG2N998uRxOnhgLzVu0oKMcagw8pUrl1LkyFGodOlyYf9EbIxw/brV 5Ot7Vx319IxIGTJkpBw5c9soLbuFgBAQAkJACAgBIRByBAIFmX/+ws9unM9BA/vQn6OHUaJEiQkB 6R8/fkQfPnygtr/+Rr917B5yIw1Cy5cvX6K5c6bTr//rRDFixLDZwoD+vWjsmBF07cZj8vIyxUDU Cpcsno/isWK9YNEqbddn95oiWVylQEeNGpXevHlDT548pixZs9G06QsoYcJEwTofZxkHqxOp7FYC EufTrTilsc+QgMT5/Aw/NBnyZ00g2HE+P378qADs3X+Kjhw7T4ePnqM8efPTiOGD6Pjxo2EKzqlT x2nC+NF03/demBpXaA/m/fv3VLPWD+qzOnP2Oo3/axqdO/sPde3SLthDEcbBRigNCAEhIASEgBD4 qgi4vOxuSSdu3HjUrHlb2rtnFx0/dpiyZcuhivj5vaN161bS+XP/UOIkyXjZujz5+PiYVT929DDt 3r2D3r3zo5Ily1K27Dn1447q79q5XZXNm68grV27gi5eOEe5cuel4sVLq/17eDx7uG3IqlXLKL63 D+XjsmnSpFX7gvLn2bOntHjRPKpcpQZ5e3vrTaxYsYTfJ6D8+QuqfdrYcufJT6t42f7y5QtUpGhJ KlCgEH1g5X3Jovl09eolypu3ABUrXkpvBxsY94H9u5nJO0qXPiNV4b4iRDBlBXjx4iUtWjibFcl6 dPfOLVq/fjVhNrNS5eqB2Jo1avGmatXvaeaMKXTo4H79iL1+UejevbuE84Qin+nbLGpcB9hUwd2M 9QHJhhAQAkJACAgBIfBFEgi28gkq9+7dUXCgZEJgF1qvXg16+uQJZcyYiaZNnURDB/fjZd75uq1h v7496K8Jf7KClYHChwuvZk6HjxhPderWc6r+lCkTVPv+7/3p1q0bFDVKVBo5YjD9r10n6tS5J61c sZg2b1qvxjN/3gzy8IhAEfh/cJTPSxfPU88enSh5ilRUqlRZ1Tb+DBnUjzJnyaorn9rY/Pze0v37 vqocTBUGDR5Jy5YtJrQTPXp0Gj1qKHXr3odat2mvyjRp9CPt3LmVMmXKQuE9PNSs7exZ02jpMpON 7e3bN6hH9450/fo1mjN7GiVLnoJu3bxB48eNorXrd7qkgEaPFo08PU0mBo76PX/uLFWrWpaSJUtG SZIkpxXLF9OL58/on39Ou52xAiF/hIAQEAJCQAgIgS+WQJCVT8w2Qs6dPUOzZk6hwux0pClkvXt3 o7dv3tK2HQcpZsxY9Pz5c6pcsTj1+r0zrVqzlY4eOaQUzzZtO1CXrr1UO/v376WXL1+obUf1VSH+ c/DgPqrfoBGtWLmZlcvwVO/HGjR1ykRq174rDR4ymvIXKEwtm/9Mc+YupzRp02nVbL62b9eCFeFP ie9REMojbD5dFYzt50bNqO8fQ+idH8/ssu1ol87tqHSZ8rz8fV7ZllavVp4m/z1eVz6rVa9Jw0eO U8zQ38wZk1UdOERlyZJNHwKUv+UrN9G3PAOJ2eOKFYrzZzDZaZvbK1cuK3aYNYY46nc2K7qYYV23 YZdyyPL3f0+vX7+knxo2dZmxfhKyIQSEgBAQAkJACHyVBIKsfHbv2p5evHhBsCeEQjWVZzXhKf7+ /QfauGGNcvKB4gmBs0/RYqVo+rRJBMVl9erlylmpdp36OvR8+QqobWfqe3qaho1ZTCiZmpSvUIW2 bd2kZmKTJjXNwmrHnHnFLGK48ObRp97zzGpQBGPrP2CYqho5cmQqULAwPXz8kCZPmcszjqbxlyxZ hgbs38McX/JMaDSqWKmqWVd5eFkecvPGNTPls2fPP5TiiWPZc+SipMmS05Url/DWpuzds5N+69Ca Hjy4z579+7i/GDRgwHBV3lG/ceLEVfU2blhLZctVVOPXPlubHcoBISAEhIAQEAJCQAhYIRBk5fPY icsE56N+fbvzsvpEWs12ld99V4NusKIEe8WxY4bTxL/G6F36+79T5TFjdu3qFUqQICGlTJlKP65t OFNfU3w8Pb20auo1VsyY6vXFi+dm+519s3DxGqve7s7WN5azHFu0aNEpQngPXfFEWcwmQt76vVHK J2xKJ00cS7t2bqOHDx/S27dv1HHYiRolYqSIxrcULWo0evXqldk+yzevX79SSnn8+D7UrkMXql+/ EXvAR1bFHPXbrHkb2r9vN/3csA6bBGSm5mzjW6NmHcsu5L0QEAJCQAgIASEgBBwSCLLyiZYjsRL0 R/+hymloxLABSvmMHCmS6rR5i7ZUyzCziZ2RI0VWS8qwZ/Tg/9bEmfrW6hn3hbeYvTQeC852OLZN hSC0VEhInVpV6MnTJ9SuXRe2TU2jnHyaNvk0O2yvT8v4pJZlS7HDV99+gy13q/eO+o0SJYoKNQXT iAnjRlKbNk3p1u2bPLvd0Wp7slMICAEhIASEgBAQArYImK8x2yplZz+Unvr1f6aLFy/Qzh1bKSHH /4zJM5A3b1yn5LwcbPyveYinSJGS7t69w45CN81axpK8M/XNKtl54xGghD5n5xh3SNz4Jg/3O6x4 aQLnKswcBleuXbtGJ04co1at/ke16/xIOXPlZQU0fXCbdVjflX5hGjFj1iKCrejGjWtV2+5m7HDA UkAIuJkAbKDhPCciBIRAyBB4yStzx48dUeZ27u7BmfvXmTLuHpe0Z59AsJVPNF+7dn2Kxt7T06f9 rXr74ceGKrwRnGl8fX1VUPNN7Hn+96Rx6nj9n5ooT+tWLX5WzkeID9q6VRMa0P93p+qrQk78SZos hSo1a9ZUDvl0lu0iLztRy3aRJEmSUuLESWjK5L+Uo8+6tauoRo3yKlQUx9sPlsSJE4dDKkUgtHn/ /n2Ck1Grlo2C1aYzlZ3pF5EJ8PkhQP2F8+fYw/46pWSPf4i7GTszZinz9RF48fwFzZs7i818etCo kUPU/WFJ4fXr17RwwVxVZsyfw+nMmVOWRay+79unG7Xh7x97MmXyBBo4oLe9Ip/lsS/1vD7LD+ML HvSaVcupQvliHKnlutvP0pn715kybh+YNGiXgMvKJ5bLMduJ/5pEjxGdypStSDt2bFEKSqfOv1M9 tikcwuGVsmdNQ5kyJqf/tW1GT3lJGYLZ0LHjJquQQZUqlqAK5YqqeKA1vjfZETqqjzY82H4SyppR IkQwhQ7CMQhijpYrV4kWzJ9NxYvloR3bNxuL69vWzkk7iGPaMj5m+YYM+5O9958pD/PfOrSiJk1a Ui6epdRicaKetbEZ29Ha1saPduGU9Xuv/nT48AHKliU11a5Zmb6vWZdix47N7Zk+Ju28EDbKKGhH O2bcr23juNaXtk97daZf1G3+SwNKndKbihXNzQp4Uvq990DVhLOMtf7kVQi4SuDSpYtUsEBWGjSw t0qDO5XDrJUvW4RmTDc97KI9lMmfLzN179aekE521MjBqgwicbhD1qxZqWL2am1dvnxJKbmI5PE5 iK3xWp7X53AuMkYhIAQ+fwIup9dESk0EgIe9p1Gw/+3bt7oTC45hH550oJhhxtCosGp1b/OyNRQz OCBZir368IqHw5NlOkzMfsBG0SiPHj1U4Y4QFRrmAABAAElEQVSwpG9NbJ0TysIUAOM2Kpcof+vW TUrE5wTF0LKMtbHBacj/nX8gbphN1Bx/0B/Y3uEA8ojhibbfvvUzq2Pt/N5xu1CQjWNEW5qgjYgR vazy18o46hdtYMYzXvz4FCtWbK2a/uqIsV5QNv5zAp9bes3Tp08qpbN+A6yYRFBmLqVK5FccDx05 q16xerJ50zpOePGrct6DOUmVSsX5O4jo1Jmrdpk3/Km2MhPasu1T0gXLCrjnP3z4qN9jyzncGcK4 7dx1xKkwbpbthfZ7W+O1PK/QHtd/1Z+k1wxd8gvmz6F2/2tOyIyYIkUKt3buzP3rTBm3DkoaC0TA Mr2m+RRaoOKBd0ARs1Q8UQr7jUqUts/RhQal1JagTVv1TYqWaYbTWN9S8cQxZGGyJ7bOCXW0sEjG +ihvDOVkWcba2KBIelgo7GjTkhmURGMUAEvW1s7PUgE3jhXblm1YHsd7R/2iDXuxUh0xttan7BMC zhBAPFv81wTRLr7hqAt7OXyYJpiB17KrYR++N/LkKcDZz1YSHoycuT7xELlw4RwV2ix7jtxUhkPI 4V6H7Nm9U614VKhYRWUhczaz166d21V9W5nY1EH+4yijG8rBLnXrlo0cY/cVJUyYiMPCeagVkypV qqtm9uyxnh0N+22N13heW7ZupJccPg9RS4yC+g8e+BIyo0Ewjp0ckQPjyJUzD2dvK2EsLttCQJmO bVi/ih48fEAlSpSxSQQrFnt2b1fOtWlSp6MyvFKJsIMQZzMKao3bu3+1MsZXZ+45Y3nZdi8Bl5VP 93YvrQkBISAEXCOApe5TbBP97bdZ7VZ89vypCmcWM2bgmXrLii9fvaRyZQqpRBdeXhEJGcmqVvue xk+YpopOnjxezY5C+XQle5qW7cxWJjY07kxGuDlzZlC3Lu0oT978KrMb7FmhUKdJm55T3VYne1nK 7I3XeF67WVGGDWi+fIXMsqV1aN+S0nOqXyif48aOpKFD/mBFPyfHJ35Ow4b0p+o1aiszKkum8v7r JAD/ih/qVlXh/xImSkSj2UY7Bz/MWcok9gEZ2L8X+fCqJxK5TOGQjUOG/kEzZi6kDBm+UZkAncko iHYd3b+WfTtzz1nWkffuJWAyJnRvm9KaEBACQsCtBPCDBsWnD2dPK12qAHn7+HA2sPE2+4A5z+FD B6ho0ZL6UrnNwnwA0TkKFipK+w+epl17jtIvzVrT8mWLORNY4KV4JLbo1cdk84zsaXv3n1RpgW21 j2xnmLk9cvQC7dl3goqXKK0ysWGmBmLM6DZn3jI6ePgfNm2JpTLCaW0OH9qf+6hPizgW8aYte6l6 9VrKaXPZclMKYWQpgwnCshUbaMnStdSPM6shNi8cF50db81aP6ikIcuWLdS6VQ6hNzidL+zx4Ww4 eFBf6t6jL2dY20gwUxg4aAQtXbKAtm+zbk+vNyQbXw2B/v17qnCEW/n62Lb9IK1cvYWuXL2kzv/f f00xq3Et/cHOg3XqNqD9B07Ras58uHHjHvJj070e3X9zmZUr9y8ad+aec3kQUsElAqJ8uoRLCgsB IfBfELh48RxH0FhKmzauo4ecpesD23xfOG+y97Q2ns6d2rIpSSTq2XuAfhi20bCZ1v7D3lETZCRD HFxtmb1lq3bq0KaAkGJauaC8apnYYI6D9pGJDU6L9+7d0TPCQfHTkmdoGeEQeg0KKsZ9795dSpU6 rd59Xg57hn2wGYcgS5lWH++N2dHw3hn55ptvKWPGTCphiFZ+CSuWmGEtV64yLV48T80kN2naUjvM s5512e7ei3bt2q7vk42vlwB8G3Zs30qVKldTPhEgkTVr9kCpn+fNm6kenrp176vDgqlM1Wo12Zxm l7pH9QNObLhy/2pZFO3dc050KUWCSUCW3YMJUKoLASEQ8gTwY4b/kLt3bnOUiXr0S9P6tIpnTPDj ZpRBA/twmt3NNGbs3yqyhnasWJFcdO3aFe0tzwiOovoNGqv3lhnJEJMYypyv7z29fFA3LNs2ZmLz 9/d3mBEO44BSuGTRPCpRvDTFjRePQ0rNUfs0m3FHWcqcHXsVtvdElBLMHMMeH8p3CU4DDLvya9eu sh3eM8qYPqlZc8ho5yjDmlkFefPFErjH8btxTUMZNIqXp8lBWUvUgvsQqxeafadWNnXqNGrTeJ9q x+y9Wt5j9u5fV7Io2utTjgWPgCifweMntYWAEAhlAoha0blzT6pT+zvasH61mfI5fdokZa/ZrXsf ZYtoHNrc+SvYTvGZvitlKtMPnb7DYuPdOz926DGl7LU45Ja3iFDhTEY3zNBG4lS4+GEvygo0JG26 DDRu/KcwUo6ylDk74Fo8AwubziWL56tkEojqUat2PVU9Is9wxudEGytZ4beUhAkSWe6S918hgfAB Dnp+/EBiTxAW0d9KmdcBM/mxY8ehtwHbQc0oaOv+deaeszd2OeYeAqJ8uoejtCIEhEAoEoCzC8To xb5k0Xy2F+tILTlLWOs27QONBst6tuTx40dmXvGw9cSSdtq06axWQfQKSHCzp1lmdLPW2Xk2Lzh2 9LCyn4vJtqCYPfLhWSNNtCxlmMlFdjQIbGSN4ux4MZ7cefLTmtXLOeTbbRXVo2DBwqopLPsvW7aI IniYQucZ25dtIQACCTgKQzSOWX3s6CEzIOfOnTF7jxlOXGNI/JIqVWr92L69u8jb20dFc3jHM6gQ ZzIKunL/OnPP6QOSjRAjIDafIYZWGhYCQsAdBOBk1KF9KxXu6Do7BiGIfL9+PdlDNh5VqPid6gLh gDpw0ofMmbNSTg7/g0xh2v9LnPrXkSAcU/Wq5WjDhrXKyQg2o1Bsa9T8wWpVd2b2cpQRDmGVEAe5 Vq1KnPWsMbNoQW1bN6W5c2YSbOycyVLmynirs/PSqVMnlHIAW1JNGvzUWKVObtHsJ5UKGCkTwRbZ pBAyR0QIwKa5XJkK6t5DZsGrV69Q3z7dac7cGQqO5nDU8OdflJKKa2n//r2q3DB2qoNNd/MWbVVZ VzIKunr/Orrn5JMMeQJBnvnEUhACx8IWCKE2LGX3rh106NB+FQsuXToO08GGxMZ4mEiXt5qffC5d Os92HzGUXVGWLNksm9Hfb+SL8vKlCypmWPoMGfX99jaQ1WP1qmVUkzMFISC8pSAX/VGeUfDze0sF CxalQoWLWhZR7/HDhic5PF2lTpNOeZpqtlZIH7p583q6cvmielozGjFbbUx2CgEh4BKB4sVLUa9e XTi95ky9XlaO6zmOs6RBMYMc5u8a2B7CSadxI3OFEV7iI+x4xiM7WFmOLwhHn8Y/11XJKxDHd8q0 eRQtalTVvmXWMmNmL2RQ6z9gmNkMjqrEfyzrYb9lJjZkdMPYYWv5e8/OqiqWHRv+3FRte/ASJULR ROPvyYKFiqjlyPPn/qGOv7XmFKInVd/Ijob6yI4GG9Ff/9eRlcJhKlEFGrE1Xmvjq1q1Fqc67q3S ItepU1+NAX+gjE+dvoC6dP5VZY/CPigbcFSqEhADFPtEvm4C/QeMULbSXTu3U4lmkAFw/Pip1KDe 93ztm1QOPExN52upc8e2/NBXVgHDNd6jZz9d+cRsPTIK/tqmmcooiGx/7Tt0pS2bN5hFsAjK/evo nvu6P8HQOXuXMxxhWOf4i6/d/1rQCc4qkiVLVlq/cbfZaFs0b0grli9RBvG4oJAyEk/eq9duU1/m eErGBYcvrmScavP69au85PWIBgwcTj81NH3hGhvEU3ilCsWVITOW02DPZU/gzYYv3vHjRipD+GnT 5/OPS0W9CmYLGjWso8KDQOF9xcGSz539hxo3aaFClGgFsezWsEEt2r17h7Kxis/ZfS5eOE89e/7B MyKm+m14BiJixIickSglL3WdYQXbi8OdbDQLFK+1J69CICwQ+NwyHGnMnjx5TI8ePlQPktaSLWjl XH2FRzm+i+CNjgdM2JpZPqxay1qGfhxl9rJVz1qmMjzQW8sIhxBTo0cNoaMnLunKMPqGnec9doja vuMg3jrMjoYyluO1NT4wga2drQQVmDzw9b3Ly/8JCemVPzeRDEch/4khHu+HD+85RXQc1Zlltj5t BHCWe/XyZaB7TjuO+wK2x7YyCgbn/rV1z2l9y6v7CFhmOHJ52R12GlAE0/IMIDwwLQVT6FA8u3Tt peLALVi0ioPHzlVhUZYtma+Kv337hv7XrhMdPnpeeavu2nOMErGt0dgxIyybU+97dOtAJUuWVaEZ rBaw2Fmlckmaz6EcMLVuTWZyTmhM7/81cYbqf+u2A9SAvV4RYBnZOzTBUxlS+y1Ztl59wSPG3rET F+k7nsXFBY+lueQpUtLuvSdo6bJ1tGbdTqUg9+ndVWtCXoWAEHATAfyIIcuWOxVPDA0rMqasZMRL 2HGt/gjiuLVMYpgNhA2ZLbFVz9o5QAFOwXapWG7EtiZQAl/yj/Pa1SuUgon9SCeKSQCjp7+WpUyz 77SmOFqO19b4wMRafW1MUDjxWXyOiqd2DvIasgSwkqApnujJ1vWEmXrLhz3jyHAvYCVCu66N9yvK Gd+7ev/auueM/ct2yBBwWfmMFSsOLVi4kv7kMCbRogV+4kVAYkjhwsXUK/5o9kZaOA4EXG7UuLm6 aHAcFx/S5T19+gRvzQRL+2fPn6V+/Yea7bf3phorhzt2HaVSpcpZLbZt2yb+kk/F8fYq68fb/moK bItleghi6K1cuZQaN23BGT8K6OVwseIL+/z5f+jmzZtUr14j/aZKwT8cJTksCVLZYXZVRAgIASEQ XAKNeEWmdOly1L5dC0qXJgFlSJeE89aXpHz5C9If/YcHt3mpLwSEgBAIdQIu23zC5sie4Die6hFr b9qMBaxgeilbJCiY39mwC7KVLg8G7UMG96Vmv7RSMefs9Ws81pTL25NnT58FyqmOJy88NV0McE7Y uWObssOqXr2O1aaePH6s9keLFtXseHpOC7aYw5RcY0NrLWaZWQF5IwSEgBBwgQDsTmfMWkRY6r59 5yaFZ293mPnYmklyoWkpKgSEgBD4Twi4rHw6GiUCE/855m82hm9DxYvm4jRxcdSM5nTO16o5B6AN hAKBo87Dhw9o7dqVVtPlDeFUbrCnbNO2o6NuXTqekkM7rFi+WHnYpUyZStXFF7unpye9DAjhgowq mOWcPm2iWqJ/8OgBecfzpnLlK1HnLr1UEF3E6dvI3rFa8Gs09P79e9Xec7ZjERECQkAIuIsAlrgz xPjGXc1JO0JACAiB/4yA25VPnEmOnLmVLRI8yR+ygwAU0nd+fmYnqaXLe/nipUqXF4M9OZEuT4v5 BceeWTOnKLtMa7ZWMBTWUsuhYQ+PCKyoepn1YetN69btlcfcd2wbmjt3fm7ntcqBDIeGbzNnUdVe vHihPPUuXjzP9qmdKXacOLR1y0Z2Yhql0sl14iDXP/z4E82eNY0uX7nEdlrJlMe7ZjMagRVZESEg BISAEBACQkAICAFzAi7bfJpXD/wOcfgqli9G/u/9afvOQ2x7eUQFnq33Y3XORrJGr4DZwvUbdrGz zjHazQ5HXjzDiXR5CJUC6d69AxUoUNjMS12vzBuwBU2Tykf/X6SQ7TBNxnrYhqH8xs176JdmbZRS mYXT801mpyiEf4gTJ54qjllQyPQZC6lmrbpsP1pWeePDu3/dulXq2JChfypnqjwclBmG1VBGO3f5 XR3z9k6gXuWPEBACQkAICAEhIASEwCcCbp/5HMqx5rD0PGPmIt0rdc7c5VS0cA4aOXKQVWUS3qLG dHkpUrAHOccJRSq3vHm+1UeLnLFzZk/n2J3LafnKTbRh0279mDXnJ/2glQ2YABizoDzg5X84GWXL lkOVhv0n5BEvt0Mp1SRhoiR0hj3gNYHTktFxCcGwEyVKZJaBRCsrr0JACAgBISAEhIAQ+NoJuF35 vH37lvJi9/KKqLNFKAQEkvd/Z0qXpR8wbBjT5SGf8sBBI3T7Sa1Yr9+7qOV8xOyMy9lNvL29tUPB fh3HYZ7gKKU5RWXm+J8QOB7Vqv0paDXMAZIlT6GOWf6BArt2zUr6noPaiwgBISAEhIAQEAJCQAgE JuCy8olwSOcC8ga/fPmCFUR/lR4Lzjl58uSj/Bz+48D+PdTr985U94cGrNBFpeXLF6l0bci5DEG6 PORErl69NiXhIPNnz5wyS5eHtqwFm0earm85fZ61Y8ZTQ2xOxMU7G5BPFnabMWPFVvHzEEPv6JFD dP++LyFLCl6XsHf65L/Hq9ik2oxnsWKlVPkRIwZyqKjkPJOZgP6aMJpz0V6iXn0Gqu5gk5qDU/nF 4SX3I0cO0sABfVSWFMQwFRECQkAICAEhIASEgBAITMDlDEfTp02ibl07BG6J9xw6clZlvOjerT0t W7pQKYAoGI2DzX5fow717TdExchEWkuky4PHuyZQBP/4Ywjl5FRctiR1Sm+202yt21XaKpcrRwa6 c+d2oMNIAzqWU/KtWLGE2nOGJs1hCcvkLVu1U7FHjZUQyLlt6yZ63mIs1cPTXZsJLVe2MJ08cVxV gY1okaLFOUPScErB8T5FhEBYJfC5ZjgKqzxlXJ8fAclw9Pl9ZjLiz5uAZYYjl5VPZ08fadvu3r1N CEeE7EWYzbQUV9PlIT0XPNqttWXZtqP3fn7v6OaNaxQnblwV39NeediChuPYej4+PoGK4RiC5yfj 9KEwLxARAmGdgCifYf0TkvGFNAFRPkOasLQvBMwJhJryad6tvBMCQiCsEBDlM6x8EjKO/4qAKJ// FXnp92slYKl8uj3U0tcKVs5bCAgBISAEhIAQEAJCwDEBUT4dM5ISQkAICAEhIASEgBAQAm4iIMqn m0BKM0JACAgBISAEhIAQEAKOCYjy6ZiRlBACQkAICAEhIASEgBBwEwFRPt0EUpoRAkJACAgBISAE hIAQcExAlE/HjKSEEBACQkAICAEhIASEgJsIBIrz+fHjv25qWpoRAkIgLBLQQu7+K7d6WPx4ZEyh QAD3gFz/oQBauhACAQRwzxljtAeKin7b9yXd9X0lwISAEPhCCST0iarOTO7zL/QDltNySCBXFh86 fNLXYTkpIASEgHsIpEsZi2LFjKQ3JsvuOgrZEAJCQAgIASEgBISAEAhpAqJ8hjRhaV8ICAEhIASE gBAQAkJAJyDKp45CNoSAEBACQkAICAEhIARCmoAonyFNWNoXAkJACAgBISAEhIAQ0AmI8qmjkA0h IASEgBAQAkJACAiBkCYgyqcThP3f+9ORw3vo9asXTpR2f5H/un/3n1Hot/j69Ss6c/oYfZT4KqEP X3oUAkJACAgBIWAg4LLyefbsCVq0YKqhiU+bly+dowVz/6b3H95/2ulga+H8KTRh7EAHpf7bwzeu XaaWTb+n/ft22BwIlJotm1bR+DED6K9xg5SyarOwiwec6d/FJlXxndvX0+qV8+nt2zeBqm/dvJqO HzsQaP/numPbltXUqH4FunPrus1T2LZ1LS1ZNN3s/9rVC22WlwNCQAgIASEgBISA6wQCxfl01MSm 9ctpzsy/qGbtRoGK7tqxgRXJQVSu4vcUM2bsQMet7di2ZQ098L1LLVp3tXb4s9j3zs+PmjWpShcv /ENp0mSkN29e07TJo6l9p35Uu26TMHsO3To3I/937+jYkX3Us89os3FOHDeY0mfMTNmy5zXb/yW/ 6dmlOXl6elGkyJH104wUKTJVqFRLf+9oAw9TceN6U8nSlR0VleNCQAgIASEgBL5KAi4rn+6mNG7S Evr48YO7mw3V9pYtmUn/nD5O4/9eTDlzFVR9Y4bY703gGcVQHZiDzj68f08JEiamtasXU+0ff6F0 6TI5qPFlH/7w4QPVqFmX2nXsF+QTXbZkFiVPnlqUzyATlIpCQAgIASHwpRMIUeXz0IGdil/WHPlo Oy9pXrtygTJnzU35CxTXuR49tJtevHxBxUtUoL27t9IrtqssXfY7/Tg2YG/56NEDKlO2qtqPmcbt 29fRFV7mT5gwCRUsUprixfNRx2CXuWb1IqpYqSbt37+Tzpw6ShUr16JUqdPTwwf3aNOGFfTw4X1K lz4TlSxThSJ4mBCgj2NH95O/vz+lSpXO7Jhq2M6f67wsHz58eMr0bQ69VMaMWfVtbQNjOcz9+L/z o/wFS3L57NohdY6u9n/p4lk6eGAHvXn9mrnmojx5i+jtObtRrkINWrF0Dv05og+N/cv+EjNsT/fu 2swzvGcocpSoPCuaTz8HnNvFi2eoavX6etf3fO/Qzm3rqBLzjxI1utr/4eNHWr54BuVgJT0lc7aU x48f0o5ta+nWzesUO05cKlS4NKVImVYv5sw1hcKPHt0nmBU8fvSQWZfQ6wd14/mLZ7R+zWKlVGJm UxNcT/Hie1P69N+qa+sVX8v37t1mprMVozLlqpGjutlz5Ff2xLauW/Tljs9aG7O8CgEhIASEgBD4 LwmEqPKJJcjnz57Se1Za7t29TZEjR6Epk0ZSo6b/o2YtO6vzXjBvMt29c1Mpn4cO7qSF86ZQ9pz5 dGUShQb0aU8pWXmE8gmFpkObH1W7qdNmpEXzp9HECUNoyIjp9G3mHHSX+xk2qDudP3eKlYUlFCtW bFYCoqi+mjeuSokSJaMEiZLQ5g3L6eXL5zzT1ZC6/NaYDrCimp4V0vAeHjRnxnhazsrDhL+XqnqO /qTLkIlnbz/S6OG9qEOXAbpCa6w3ZlQ/NleYwEpwOqWoTp44gnr0HkGVqtQJUv+zpo/l8x5KmTJl Uwr7JN4uV7E69fljnLFbh9v4TOrWb0bj/xxA+/ZuM3swMFa+z9w7tmtIN25cZeU8LT19+pgV1r5U 58em1O63vnT+/Cka3L8LZeTxpE+fWVVdsmAazZw2lqJGjcYPALXVvmNH9tKQgd1o9IT5gZTPf84c p1bNalJ8VuYS8ud088YVtp8dTENHzaD8+Yup+s5cU1cun6dfW9Vlhe4V+SRIyCYQo9S1oRoI4p/r Vy/R8ME9KHHi5FSwcCm9lUkT2DwhQxZq2vw3mjV9HD15/IgfBl6p7egxYxGUT0d1oXzaum7x0OSu z1oftGwIASEgBISAEPgPCbjscOTqWI8fO8izjN/SivVHaOGKvVSgUAlWMKcSZtEsBQrKe14K3rh+ mX7oNM+o3bp1g8pV+F7tGzO8N/n5vaU5i7fTqLFzafm6QxQ9eiwaNfx3vQ42dm5bT5OmraTVG0/Q T43aKmUSs3VT56ynQcOm0OJV+6k0KwaQMuWr04p1h+mvKctpPJsBwFbz6OF9dO7cSXXc0Z/KVX+k PPkK09LFs+iH74uqWS/M8GmCc4Di+VPjtjR30XaavWAr/TV5KcWOHU8VcbX/KzyDDKWsza89aOLU Faq9Tt0GsrK9lPbt265169Trv+woVbdeM0qcJBmNYwXZljf4aOb+gGeOp89eR1NmsmPOyv1K8Zw/ 52+eMd5HxUpUVEr1ru0b9H6P8iwvZO+uLfq+XTs28nnHpVy5TeYJ+gHeiMX7hwyfQguX7aHR4+bR /KW7yMcnIS3iBxSjOLqmxv/Znz7yEvqcxdsU779nrGJF9qpq4l/619hUoG2cI2bBtf9XmbUzkjxF Glq8ch8lSZaCcvK5YXvarHXOVDUrY3nduvOzNutI3ggBISAEhIAQ+I8IhLjymYJ/lDt3H6JmA8OH C0fFipdXM44P7t8LdMppeCYzLf/fyl7jmqxfu0QpK0WKl1Ne9DvYqQkOIDGix1RFokeLQfnyF6Wz Z06YKbQNm/xK3/AsHMQzgifPgMZRS/e7ub62T2ujRMmKens4ljVbXlXmzu2b6tXRHw9ech81bj79 1qU/L6n704B+HalBnZJ086ZJ4dm6eRVByatUxTT7h/aysSmCNoPmav9Y/o3CinRNgzNTeV4+9/Ty osMHdjkabqDjXuxk80uLTrxsfpZWLZsT6DjMHLayYxhm8aBkadKsRUfy8orIXv6rKU6ceMw7K+3n 2VPIK55VPn/uNOUrUIyOHduvK7VYNodyppk7aG3hNVGipJTbYDqAcWHm78H9u8ZiZO+agtK/nxXw Euzwk8AnkaoHE4imLX4za8PWG5wLIhto/wcP6GyraIjst7xu3f1Zh8igpVEhIASEgBAQAi4QCPKy O2bIoEwaBQqWEsN+Ty9PYxGKHiOWev/61Uuz/dqbUmzviVm9u2w3lzBBYtq9cyMraSUJigiWYeGd PX3KGOVxr9WBnSaWveFlrkmCBEm0TfWK2b2j7NXdsd3PhGXyH+o1p/LslQ+BTd782RPpECtuT548 JL+3b9V+zJ45K1BAEQGg2vcNaC7PcsLrv2eXFjSdZ1pv37pG3t4JKGnSlFabc7X/2zev0fPnz6h0 kQxm7YENlnyDIrD9nM9hsqb+PVJFKyDDZ3iLxw++UASNAjvOePG82aTCpKQXZPvMKZNG0LNnT+jI oT1KQf6leUdq1KAinTpxiHzYPvfypfPUsPGvxmbMtg+ycopwRzjHVy9f0jM+z4QJTUqkVtDeNXWf FVVcDylSpNaKq1d4sUPC8T97UqNWQ2rb7tMsukeEIN8i9rqxeczyug2Jz9pm53JACAgBISAEhEAo EHD5lzUuKxsQX7YBhHJoFDjyROOZyJgBCqbxmOV2OINyYzxWgR2FJo4fQht4xhNhfu7euUUV2GEF EjFiJPVa76fmVJFtJY0SKVIkNXuJsE3WBLaNcKg5zk5Fs9mms3ePNuTLCi4UobYtatMLVpga/dKe kiVPo5aXu/7WxFozDvdhRq/Bz23oypXztG71EqXYhg/voWxJbVV2tX/PiF4UN158+nv66kBNxmcl N6gCpatFkxo0jxVx48cTIUABe8fmDpbyjp2nogfMQpcoVUl9dnhgOHn8EH3DDlWZ2A7Xm5fOsdye IEEiZfdbqEgZy2bU+x3snNSFuVepWkfZ4kaPEZPGje7PdpQPrJa33IlryiNg4O9YEQ+KePK5IryS pWjX64cgRGYITt2Q+qwtz0/eCwEhIASEgBAILQIuK59aOJ4tG1dQvQYt9XEisPzhg7spRUrzGSe9 gJMb3rxUmjV7HtrGQc7v37tDiRIn1cMX4VgMVkjgoJQ4cTInWzQvhuVu/G/epBorRBuoVJnv1JJ9 lx6DdacYOKy4IrBfxdK+UTxYCYXCi/+Jk6Rgb/917FRyS3nna+VQz5cdpGAy4Er/yZKlZuV8mVJo LR8AtLaD8pojZwEqzJEDFsydzLOWJicttJMoSXJ1HrC1/N4Q3xUe2HjgSJ/B5GAEr/TkKVLRHvaI x7Eq1X5Qw8iZuwAd3L+DHYkSUJZsudSMqLXxwXM8AT/QdO05XD+McTx5rL91uBHPOyFF5QcgZDMy CsYTHInNZgWQ+/zAogmc317wzKxRPMKFDzT77GxdYzvadkh91lr7X+sr7r2Txw9SxoxZ9EgMXysL d533tasXlXNhfL4HRYSAEBAC9gi4bPMJm7xsrBzCax1exPBQ3s+KRYe29QlfPu4IFl+2fDU6d/YU IctOcbbHNAoUms0bVxG85B8+9FVLvLt3bVKZlYzlLLfhbY5yyOYDJw6lwPIyeMzYcQgze1AOEZ4H Tka9un9Sqi3bsfa+Qd3S7OndicMe7WSv79M0e+Z42rhuOcFOFUopluIj8Guvbi0Jzkdg1qtHK/Yw 7x+k/qvVaMDmCzHpdw6KjniiSB0J9jOmjaHr1y6pISIzT+miGQIpYdbGb9zXhmc/X7C9Jpy8NMFs bkW2V0VCAPRx6+Y15ZDze7cW7E2eiKrW+BReKV+BEvwQsovHcZmdy0qpJgoWKk0Xzp9h28+DVLho Wa3ZQK9wOIKCjs8Jpgjoa4/BWSlQBSs7YApStFgZFdpr+dJZyu72z5F9aMWyeaq0I4cjK02qXQnY ZAAxUeFtj7BSCB3Wqml18uMZVt3chEvG45nnCxyK6jCHEMMsO8TZuqqwxR9nPmuLKl/kWziAzeTr 4f/tXQV4FVcTHdwTKN7iULRFCoVSftxdgrs7Ka7F3d3d3d3dWrxQvMUl0CLBApV/zg277Ntn+yKU wMz35e3u3atnX5LZuTNzAp/lQoesXFj4fra64/fP3QukVdYwPO8PlYHtQ5tbp3b1aCynbBMRBEIS gbicecabdQGzRLp9g+LzLmYE/r8tEvYQ8Fj5xBKHjJilLGSzZ4yjBrVL0g8tqtM93h4fPmYO5ciZ V0cBaYtgATRKBC6DIC+mOjqog5RK3t7eSrEsU76Gqqd9NGvRhZW5OsovtHTRrFSsQEbq3/sHVVf1 p/X79qi1g4LZvVMzyp87FdXwya8sbD+0700IWPLl45nTx6hUkSzk27xqIEMTp2jC/F31qfVdpVoD laaoTfNqHGhUlKZNGsFBUT7U7cfhqgqstH0HTaQ7t69TI/Z/BGb45wgmqKCMj/yXw0bNVimW6tcs QQXzpKHqvKYdbI2O+Na38cGD+8ovNGIkW4usNmcc4c+oPQ+tHAFFdeu3UpdeBpYqbMmXLV+d5jBz k0+53OyqUF1ttyM7gHGbGsw+T548URZr5EuF5OEMB8g08Pr1K5VSSxU6+GjYpB2lZ0tUB9+6VCx/ BjrAW/XlK9bSvytoYuU71bHLQJWuC6mfqpTPQ2fPHKf+jD/E/H1UhW8/8ILgzMcTPr1d+Xn6+z9V PqyD+nekajWbUGbOr2rEsG6D1oo0oVXTKtSrRyCOVtrqvw+m762VZ21cw8d2jpfFNi2qEvDczK44 l/ildDqnVsOLkFmQ7gvuMuNH9ycEKoaEYJyd29bpXd24fpXGj+mnXtD0wv/oxDy3/2gaMqwgEKoI xGQXrrSdmlNUU/aZlL3b0ucLptE/0WKE6vjSeeggEI6tNm+jhAIHuHnXn+7ef25pNEQWQ6GKy1uS WhJxY0NsxSNQBcFCRkFgELajIc7qYFsMAT+an6exPc4R8ASebigLCXmr1hj8ZOzf2A4pmmDxjBM3 vp1fKiK67/thmz85QVlAXePYzvo09o9cmAHsA5mYo7YdRXOjLgKpIrFSG4+3oI0S1PERVQ5FM378 hGq7WeuzWcPySlFzlasUa4zE0epG7LT2jlwJcA/P/O5tfuNkC58RH60djlAY8FyMrgiv37AP5j// UuQoUYxVHZ6DDABKNDIU4DkjT6z2HXL2fXH0fGDBxXdIo3o1P1Pz4K7w0OpiPvfYOovvHL4nwAk+ ncbnjTLUScDbj0aM3LV1tAZtXBydPWtjHSvniRMG/rG2+ntupc/QqtO3Zxs6dHAnDeUXXrjLQIAj WNGMmKO8aYNyipgA1vKadZpTyzbdUexQrjJBRc0qBWnw8OkEX2VnYh5rG+cHRiDh0lX72MXoS2fN 3ku5eW7vZVAXg1Sp8L3KeTtgyBQXtT6MWzkyJ6RjZ+5/GJORWbhEIALnTs5SKR89T5mGLs5eq+p6 8c5T+g6N6XLvEfSoQqB7l8tO5OZ/jkDalLEptndg3A4mY2uW9HB6+OfrLIJbdQ6rZ6Dx0KZnTfF0 VUcpLiY/SmMnUJiSJE1hLNLPjf3rhXwCRcDZPwwoRca1GJUG9OGsT2P/8El1J858NIM6Pvwb8WMU 5N2EZXX2gi3GYrtz8xqNFYyKo7Ecz9wZ7lo9oyVUK9OUR+3a1dGomOM5G9sqhcPNd0rrG1Zlo7ha L+q5u486mA9SQmniCCeUGb9LWl13bd19xxw9a63vj/GoGMnY6tiAgwI1xRPrBI7hTTsqG9cvpSuc SWHh8l0eu2pAEcWuAdw+8hUoYeOXbWRgU7lf2a8dApeguPwSi3kZ04/hnhVGK9Szyta1j33Tf2Uf ZvxeQVFOxvStEOPcVAF/wLf50IEdKvMHAv3Csw8yvjdFmM3NyP52jwMzwQCGlG3oU2OIM/bjjj0N 8z/NfrN4EYPvvIggEBoI/M07fTcbtKKUYwaQN7/8PWFXvOR8/pRT+4niGRqIv58+g6V8vp8pyiie IgBKyR/7jHarJHrar9QXBN4nAvChRvqw4kwC4Urg84z0bDVrN7HLwOGqHe5tWLeESRKOUnJW6EBE MJtTjY0ct0CnjTUysO3ggLiDrNhB1q9ZrNwtYOE3K59WGK3QhxW2LrgUITAyW47v6cnjR7RuzSJa tf4omiu/d40dDtdrOUfv8MHdKGvWnPTE/zFdunBO5UhOwYxkUD41Fi34bINSF8QSd9hdCsxcs5k8 QlNArTBqjRjag9nlZqkAQ/+nT2kRZ8gAo5iIIBAaCDyo3ZQSrl1KyccNpvscTxD15g26PP9dPvDQ GFP6DF0EguTzGbpTkt6DiwD8LvNzMn8RQSAsI/D7b5eVS8OKZbMJW7qF8qajqhXz0ISxA2wIJaZO HEJR2H2kLjOZeSpX2VI4c+4GlY93AVtNw7Flf/L4QQ67AVmGb/s+6t7oCQsVixXocYMjrti64Iax acMKRQABt4MpM1bTjLn2vq7a+DOmjFB+2ROmraD5i3dQ8VKVKBL7fKOdUaBET+Xty4XLdtOEyUvJ j62gq1fMU1WsMGrBtxaKZ+16LRUb2fptJ+lrTqmGzBcmLy7jsHIuCAQdAd7puNa5H0Vlt7lkU0aS X1kfesWp/ETCLgKifIbdZyczFwQ+agSeP/NXygwyODRo3FYFjX2bK7+y1M1iMgMI6E9Ba4ugQaN7 hhEY+BtDkdN+4CupSfPW3XTyBLjEgHXs1MmjyrdZqxOaR1dsXZHZTShWrFgqRy628iFgEnMkWKMf s8ZpW/Kok+2bXKoMPthGad22J6VL95UqQh5eWEBvXP9NXVth1NrJ2UbApgY2LghcYbr3GqWCDFWB fAgCoYDASw5G/TuKl6IJec5b7iJhGwHZdg/bz09mLwh8tAhomRqGjZ6jB69BOTzH2QtASNCsZRca ydu/yCMLX01nUrNyft5Sv6bfRk7dzFlyqmuzn28SzskLhqxHnL7F6HusNw7hE1dsXfCv7tRtKG+l dyWfMrkof6GSBMYwR77lULy/TJuBNjP17nffF+TAq3i0cf0yRVds9sE2rxl+ny9fBm6ZW2HUusdB kwgyNftUI6MIgu9EBIHQQOALTpf4b8Rw9DRtNkoyfRz9ydli/jH59YfGuNJn6CAgymfo4Cq9CgKC QDARQLYDyJNHf9goggkSJVZ5Y2EN/JkDgMD2ValsLn00KI9rVy/goKD1NG/RNhozYTE9f+Gv30+a NJXKeqEXGE6Q8QAS8y1rl+GW5VNNAQsKG5Y2iNZHUaYb/i5PQVq7cj4tWTiNjh7ey0FVuxWbm1YX R1hzoVTC+om0a5BUqdNSn4ET1bm7D208K4xa4cOH4wwUf7nrUu4LAiGGQFTOjZ1wzTK60bIjPclX mL6uXpI+nzycbnXqH2JjSEfvFwFRPt8v3jKaICAIWERAY85C4FGpMoEUu2gKQgXkzgWVb+fug+lv TqdllNHDe3G+2CxsDS1OUTgHYJKksYy3bc6vXjlvk2rpF873CzIBs7VQaxSBqXIhz9glwJkEh9HK UZ+wMNau14oyZMpKLZtUprOnjzOBQyGbqr9zdouzv5ykxSv2KBY48ONqAUQ2Fd1cWGHUgnV488OV isBBy+qAzARmti83Q8ltQcAyAimGdKeAz78gv7ot6F/OTONXpiIlWryA/JjA5fV/nPLM8iKkog0C onzawPFhXNy88RvnGQ2gNF9msDwhcxvzteWOpKIg8IEgkOv7ApwzNwnNnDpS5c6FMrVw3mRmz/pN Bf4g5ZJPlfp2sx3HLDtQXB3dM1eeO3uCyktbvJSPIjWAJbVJ8w7mavo1cvhCwJ6F7WoE9CRNlkq/ jxMjo1WGjFk5D+89lZjezIZl08jBhWLSYvcCMKTB1/PIoT2KcCFZctvx0DQ+p1VKwLl32zBJRnLO hwjlGflts2XPzexk1VVOWgdD2BWBUWvJoumKPa19lwGcBSANByTdob2clqkABzEish/9zWayiYF9 21O7Tv3oKUfhDx/SzY7ty65zKRAEgoBAHM7i4HX2FF0aPFEpnujitm8Pird9OyUf+iNdnrI0CL1K k/8agSArn9jm2cS59cAKU4L/cJsF1gr88cQ2Vo5v89gwH/3CPluXOGLSkSDJe272WdIE0Zega3zy +E/KmCkb4R+SObm0Vjckj1DesAaz5M1XzMbnCkEMyHd3jrcFEjHVZM7vCtjxzlupYxwHFIJIobJg 6S5jsc050rT8wdGlGp2puY352lzfpjO5EAQ+QATwez5o2HTq+2Mbat4oMN0Sclf27j+W/pe3qNMZ hw8f0YYVy1FFRLVDevQaSdOnDKcFcyerIJqyFapTPc4rqomZUSsjWx8LFCrBqZaWqJ9OXQfaKZ/w 1QQbVr9evooNy5vZ0ho368D5R3fYsGGZ+8aYGlsWGK+82e1g7+5NTCs6QU0ndpw41KFzfz2FmrE9 sILFNUbMWJQ9Rx71d/c3zl86qF9H5aIA1i9nLFpg/UJfEI1Ra9igLgT2NAi25L9Ml1HP5ZmYqWZ7 9x9Ho4b1ZEa3YiqdU92GrenEsUP6GKqhfAgCwUWASU2STRpOT5hJ7nGJinpvfzFJy+26DSjZ9LEU k/WDZwZmRb2SnHzQCASJ4QhJmQf0bceJj09RBo5Am7Noq75IMOB0aV9fvaWnz5iZXnIOviuXLzAV YWNq/9Y/YxjnooNjvFlePH/G+fWy0qz5m9WtVSvmsrN9d8Ufjj+s58+d5n86RWjQiBkOI1tBfYdc d/U5MtbsDG8ey931qOE9adnimRQjhu2WXc++o/mfTynV/DErxG2aV+FtwKvK2d/P7y4FvHrF/zCn 0be58lmuY54LOJLdKZ8tmFf8AadIWbHusGpubmO+Ntc3jynXnw4CYYnhSHsq2Na1upVshakK/aIe /CTxN+v2zd9VsnRzMI4zRq1HzLry5k2AzYuoNlftiBd0V2xYzvrGy6qRcMAZc5qxPXJzzmJr5MZt p5RFVpuDb8tqigFt8fI9qsjcNwoRKQ/F1PxSb4VR6y4zeWkMc47YvtSgH+CHMBx9gA/FyZTC8e/D v/x7yl9SuxrhWL/4l3cgRD58BILNcLSLuY779fSlgoVLcQLoALsVr14+h1ODbKehI2fqStpQfote umgGlWMaLGwld+42WP0YG4N2sgpzhmvc8LA8DhvUjXyq1qdOXQPz7oGvuXeP1rSZozjLV6ptbK7O L1z4RVkwyjIffHCVT9CC4m0f+fKcyQj2Q3ngd5+WMNUefNCQ0qRJ/TI0eEAnPRG0lTrO+ndVPpE5 1UExaFU8rW+1X6knCLwPBDyJPDcrkM7mp9WDpdKYoshYXylkgUZBY7GyENoUOLhwx2jlrG+j4olu HUW3o9zYHgo0Xt737NpIRYqWVzS2v/JuDKyfuXIXQHUl5r5R6CxFlRVGLVhBNXHE9qXdk6MgEFQE /n1Lxe2ovSiejlAJG2X2rxJu5u3l5U3jpyzjbZfx/IYd0642/JKSJkuhK56ooG1j7dy+zq6+VrCI fbmwXVa1RiNVtI4ZRJC6oxX7dmiC7X3kpNvOlHtmMVPfrV21gH3DrujV8FaO9Cwzpo6ghfMn0zmm qwuOgFXl8MHdKpEzFE8I/KwqV21At2/doDMcuGCljqs5YM6w5E7mJNqg2DPmJwS13v6921w1t7nn qL47TEDHt3zpLEXLB/eHObPGKVaWhw/v2/StXYBLHdv7d9hlwCiwtqAfvGBAwGMPjuwpvC48J0f9 4XnOmDZSrX3r5lUEK48mxnnhZWg8p+AAnSgEOKHfOTPHcu7Cq1oTOQoCHzUCVas3orz5ilL/3u04 Gf+XVJgT8jepX5bpP3PzVv2Aj3rtsjhBQBAIewh47POZ49v/uVzl06eP7SJFEzHneZw4n9kog8ZO oExAwchXoJgeoXme39pTsOM8nPqNkipVOsK2v1lcUd9h26pTu/p0g+nzUjHVHLbLx43qR9VrNaF2 HfuZu7J0ffnSOY54fUpZmMrOKOnZJwxy9cqvnCD7H7d1MrMviyOB4tqgVnF6ztaMSJzDbw5vqRUr UYH6D56sqhtp/xy1N5eZ61vBxCodnzZWBPYNmzxhCF1kC3TPPmO0YtrGz3bEkB70Tfbv6R4/iw5t atHTJ48pNVvBly+ZTVMnD6Nho+bQV5zwGtK1YyM6emQfJ8LOpHzRFs6dxAEeC2jy9FXqvjYvjLNl 40qKzT510aJH52CUSU6pCFVD+RAEPlIE8HdyxNh5hK3ye/fuKKYmvBRr1t2PdNmyLEFAEAijCHis fLpbZ1KOxNy2eY1NGg78QUTCaDCWOJJVTO0G3uIatZvptx8//oNiecXWr7UTOO8/f/5Uu9SPoL4D /3HPri0I1HcpDOkXxo7soyJO5zB/scbDPHpEL86bN50ttCWZCSS33o92Aif7a79doZJFvlbbUvBr Kluhhor0xHYagn0gsVmpNkrcuPHVJdZjpY6xrfEc1tPq7Cf7AyvHGG/MyN60eME0qlytgZ3Ca2xn 9dwTTDQ6PrCiIIisYd3Sio6vCSe8Nkp09o/NzQFhh/bvVPSH2jYcLNVIgJ06TXrq0bmp8rVbiJQw nEsR1tLGdcvw+nrRjDkbVHfFmMu7e+9Rei5D+P4OHdiVLlw4Q+nTZ9aH3Ld7C02bvY4D0bIScj4W L5BRBWRUrtZQ1fnzz4d6XTkRBD4FBLBVnjqN16ewVFmjICAIhGEEPN52d7fWOpyPLkaMmNS0fjnq 0rEh/dCqBvmwL+fDB34qMt7cHr5KUD6/zvwNBxu942p99fKl2nY314cV8AXfsyrY4sXWbDGOlNMU T7Rt1qITRWY+6J3bAxUec38VfepQlx5DqGOXQVSnfiuKwC4AA/q057QvI1TV52ythUSKFEUdtQ9Q 4kHg/2mljtbOfATtXjsO0ILiCcEcIAf2bVfH4Hx4iokrOj7zPMqUq0FQ+jSXgCdPHim6wqKMP7bO 9/K2OHI2QvGEwDf3u9z5VTAZ3AAghQqX1u/jOkvWwATid27bbueD3g+KJwSBYVapCFUD+RAEBAFB QBAQBASB/wSBELd8wuI4f8l2Fc1++9Y1ip0yLTXg1CU9u7e0sxJixTu3rVU+kqDKMwpShsCB3iyI UMU2q1W5xXNA8FCq1OlsmsBKFy9eAo5GtVVotEqob2xTiX05sQ0ORRkWP6+3VllzYuUA9m+EIDrf Sh1tPPPRTLsXN24CztvnzdZUx/6W5vaurj3FxLx1Z6TjM48DNhaknNq6aYVSIrdvWU3/Mv6ly1Sh u7dvcJDaa/bHHM9b5FP0pmCkwTOCb2gkVkphxVyyYCqnsNpPjx49VBkEUPkfUzLxRIneBTt4QkWo DywngoAgIAgIAoKAIPDeEQhx5RMriJ8gMdVt0EZfDCxhD5j2LUPGLHqZdgLKODCKFC5WTitSR2y5 37l93aYMF/BV1Gj37G46KEDQEuT1W9o8Y5XXHK0fyyKNHiyQX7IP4sULZ1XATJzPArfXH/jdMXbJ inTgnONzHjIrdWwau7l49eo15/EL/pZaSGACtwRHApwKFS3LPpoLVaDSju3rKWu2nIoeEc8OUrte c+W+YGwfNWpU3drp26Ia+bPFtGHT9hyFnEa5THTr2NhY3eG5VSpCh42lUBAQBAQBQUAQEATeCwIh vu3uaNbzZo9XeeuKFK9gc/v0qZ846vwUla9Yyy7H3DfMzAG/R2PEOvwDz58/S7nzFLbpR7twRH33 eZLkauxTJ3/SqqnjlcvnOcraTzGh2NxwcYFAJ0TbR2Z6L+QwRRDVkcN7bFog2hq0f99xonwrdWwa Gy4QFIVcgpoAq4CAlyoISysL6jEkMXE0B6TUgtV62ZJZBLpCsMdAkDIG2RKQwxTBEMYfWHYht25e U1vwtdnNoHTZauyOkZ3ggmBVNCrCvoMm8YvKXUVFaLWt1BMEBAFBQBAQBASB0EfAY+XzCUeznzpx RP28ePGMXrJvo7o+eVSlAjrLASlIafSAE66fP3+aRnOydgTK1Gvka2exRHQyLHk+HERjlpJlq6p7 yOsJRiQoiz06N2E/0AhUgf0xHYmR+g6pd5ArFLnwSperRrvZ73MuK8FQbpDGp1f3Fip5vaO+4Kf4 Y9fmdGD/drrNW8VYB9hKkFS/5tugKOTGQ7L53Ts3qdRNGGvDuiW0euUCKlaygorSt1LH0TpQBsWz RZOKKnUQFM+hAzsrJpGSpas4a2K5PCiYWO6cK6ZMlZYyMlnAnJnjKErU6DozCvooV7Em7di2nhB9 jxRLwBo4L2VKP4g3K/SwzO7ZtZn++MNPBRn17tFS3XP1gUCoieMGqjRP8Lc9csg5FaGrfuSeICAI CAKCgCAgCIQuAhE97X4H+/ANY9YhozRrFEh7tWbzMWXVQq45WOkgCdn/ryNT0FV5G4GstYPicZCj osuUq0reDqLaE3N0+Ygxs2lgn3bUuF4ZRfGWMnVaGj1ugR19pdanM+o733a96G8OZkG6oknjBinl Bml9kN4HuTnNAh9HzK9L+4b011+B+SXhxwgqPR/2/dSkAye/f8F+ijOmjlKpm0B/V6JkRerUbYhW hazU0Su/PQHVXf6CJdiCGkvNAf6Qn3+RlIaOmqWnnjJS66GZp9dWMAn/llFCO2rzNNLxaWXmYxl+ ecD3pAhvwRvTZTVr0YWZYd5wLs6hip4P7YCbxsMNy6Vv+97qfqkiWZSfK/LE3r8/XqcA1OajHdGH OypC1BERBAQBQUAQEAQEgf8egSDRa7qbNqKp79y5wUpFXDtrp7GtI6o3433tHFbAiJEjWWYtckZ9 h8h6BL3ET5DIUv47zO8+J0Z3tw5EcWOLNxGzfWjR6drctaOVOlpdRH3DpxIWSmy/v2J/VeRKNQr6 g1KqsZN4eq315Q4TR8/IGR2f1ieOsGZ28K3LuQfncvLrYsZb6hwJ8++wfyyyCGj0fMZK+A7dZ3/a z79ITggm0qgQtTqO5oV78CsNYF9eWMEVA4zWQI46AmGRXlOfvJwIAiGAgNBrhgCI0oUg4AECZnrN UFE+PZiPVP1IEejYti5dOH+G1m4+oZTHj3SZYXJZonyGyccmkw5BBET5DEEwpStBwAICZuXTY59P C2NIlU8cAViejxzey64DpUTx/MS/C7J8QUAQEAQEAUHAjIDHPp/mDuRaEDAjENPLi2bMXU+pUtrm VjXXk2tBQBAQBAQBQUAQ+PQQEOXz03vmob5i0GoaaTBDfUAZQBAQBAQBQUAQEATCDAKy7R5mHpVM VBAQBAQBQUAQEAQEgbCPgCifYf8ZygoEAUFAEBAEBAFBQBAIMwiI8hlmHpVMVBAQBAQBQUAQEAQE gbCPgF2qpX85/6KIICAICAKCgCAgCAgCgoAgEFIIIH+5JnYBR/7PXtPzF2+0+3IUBASBjwyBGNEj qRXJ7/lH9mBlOZYRSJQgBt3ze265vlQUBASB4CEQJ3Y0iholgt6JbLvrUMiJICAICAKCgCAgCAgC gkBoIyDKZ2gjLP0LAoKAICAICAKCgCAgCOgIiPKpQyEngoAgIAgIAoKAICAICAKhjYAon6GNsPQv CAgCgoAgIAgIAoKAIKAjIMqnDoWcCAKCgCAgCAgCgoAgIAiENgKifFpA+M2bv+jgwf3k7//MQu2Q r/Jfjx/yK5IeBQFBQBAQBAQBQeBTRcBj5fP06ZM0a+YUh3hduPArTZ82kf7662+H9x0VzpwxmQYP 6uPo1gdTdvXqJariU4r27tnudE7Ij7p+3SoaNLA3DR3STymrTit7eMPK+B52qapv2byB5s6Zrn4W LZxHJ47/HJRupI0gIAgIAoKAICAICAKWEfBY+Vy7ZgX92KOTwwG2btlIvXt1ZQvhE4f3HRVu3LhO KW2O7oWVsoCA11SqZAFq07oJ7du3izZtXKuU1RnTJ33QS2jerB4NGdyPxo8bSQMH9KQypQtRieJ5 6e7dO8Ge99WrV6h/vx/p6dOnwe5LOhAEBAFBQBAQBASBjwcBj5XPkF76ylWbaN+BkyHd7Xvtb97c 6XT61AlasWdR5AAAIq9JREFUuHgNbdm6n/buP06bt+6jr77O+l7n4elgf/31F1WpWpOOnbhA585f p0lTZtOF879St67tPO3Krv4vv5yiyZPGkt/9e3b3pEAQEAQEAUFAEBAEPl0E7BiOQhKK/fv2qO5y fZeHNm1aS5cvXaAc3+aiggWL6sMcPLCPrWNPqFTpcrRz1zZ65u9P5cv76PdxAn/LBw/uU4UKlVU5 LI2bN6+ji7zN/0WSZFS0aElKmDChuge/zOXLFrBSVZv27d1BJ04co6pVa1G69Bno3r27tHbtSqUQ ZfoqM5Ur50MRIwZm3McYR48coNevX1PadBls7qmOXXzAyhc+fHj65psceq0sWbLp59rJSZ7LgQN7 eYwAKly4OGXNll27pdbo6fi//nqWLa276cWL55Qje07Kl7+Q3l9QToDvvLkz6eefjujN3eHiCNOj Rw/RQV4nZP361RQ/QUL6jr8DadJ8qfcrJ4KAICAICAKCgCDwaSIQqsrnzJmT6fGjR/Tmrzd069YN ihE9Bo0eNZTatutMnbv0VIjPmDGJbt64rpTPA6yswgf0u+/+pyuTqNShfUtKxwohlKM7t29R7do+ qt8MGTLR7FnTaPjQ/jR7zhL6Jvu3dPv2DeUW8Msvp2nVyqUUJ85nFCNGDDVWxQrFKVmyZJQkSXKC +4A/K7316jehxg1rqe3yTJkyU/gIEZTFbsH82bRq9WbVzt1Hpq++pn/++Yf69O5KAweN0hVaYzts QU+ZPI4V2/QUPlx4GjVyCI0cNYmq16gdpPEnThhNw4cNoKxZs7Obw1MaMWwgVfKpRhMmzjAO6/F5 rJgxKVKkQPpFd7hcvHCeHGEKpXjH9i1q7CWL51KECBEpIv+I8unx45AGgoAgIAgIAoLAR4dAqG+7 //TTYfqKrYzHT1yig4dPU8FCRTlgaSohgtss2ALGVvDq1cv0WwiCuXH9GvlUrq7K+vTpTq9evqLd e3/ibe7V9NOxXyl27Njsa9pFb4MT+J+uXb+DTp25Qm18O9GCBbOVErqZt8VnzFpIh4+epQoVq6g2 FStVoZ+Pn6fVa7cS3AD6DxhGRw4foDNnTtn06eyiZq36lDdvAZo/bxYVyJeDx5pDf7MyqgnWAMWz jW8H2r3nJ9q5+witXL2F4sWPr6p4Ov6lixdUUFOPH/vRmnXbVH+Dh4xSyvae3Tu0YT0+/vbbVcLz 0iyy7ublDNOhw8ZS776D1fgLF62hQ0fOKCXb4wlJA0FAEBAEBAFBQBD46BAIdeUT1i4oI9jeDhcu HJUsVU5ts9+7Zx/UkjHjVwRr5gbeqtVkJVsv48aNRyVKlFVR9Nu2blR+it7esVUVLy8vyl+gCCEK 36jQ+rbtxFbBb1SdSJEi0mefxeWtez/atnWTXqb1UbpMBdLOcTNnru9VnZs3rqmju48IvOW+aOla GjBwOM8hgDp3bENFC+em33//TTXdsGENIRq+WvU6elffffc9FSlSXF17Ov6KFYuVIt24SUu9v0o+ NShy5Mi0f/8evczKyaGD+6hjh9ZUr25VKs1BU7FiedGgQSNVU3fzcoWplbGljiAgCAgCgoAgIAh8 eggEedsdyhSUSaOgDGIsjxQpsrEKxfb2VtfYKnYk5djfcxhvo9/m7fUvvkhC27dtokKFi7FiFYlg mYNP5oTxI2nqlPF68zdvXqtt7xcv3uXhTMJtjdKseRtlzWxQvzplyvQ1NW/uSz5VAq2pT548pmlT J9B+9p98+PAhvXr1UjU1Wi+NfTk6hwLasFFzqluvCVs5x3IUeV9q0byeCkC6xkpookSJKWXKVI6a kqfjX7v2O7d5QhnSJbXpD9g8f/7cpszdBfxF8SIQP35CatehK9Wp05CiRYummrmblytM3Y0r9wUB QUAQEAQEAUHg00TAY+UzAQePQO7cua2UQyNsfn73ycvLm7fB4xiLHZ4jQMeRVOWtd/gyrlyxhBCo dOvWTaparbaqGi1qVHVs3sKXqhqsiCiMFjWasl46SxMUPXp0Wrp8PR05cogmTxxNbdo0oVu3b9IP bCGtXrUcPXr8iNq168p+iWlUYFKTxu+slGpQix+w8LZu014FQ8FqCwUOfqQR+MeZeDp+FLZwxo+f gNZt3GXXZeJEn9uVuSoowsFa/foPdVjF3bxcYeqwQykUBAQBQUAQEAQEgU8eAY+VTwTlQNZx1HiL lj/oACKx/MEDeyh1MCOaE3/+BX2bMzdt5K1qKLhJkyajPHnyqnFwz5stpwhQSp4suT62JyfY7sZP xQolaBtbVctXqKK27IcOG8Pb4rVUVwik8USw3Y+tfaNEiBiRoJxFjx6TUqRISVs2r1eKdJIk76yV aAcLL1wGPBk/Veov2S92OQfxRLB7ATDOITjn165dszwvM6ZQ6GEJhiCTgYgg8CEjgB0V7HbA7UdE EBAEBAFBIPQRcGx+dDFu3nwFKCcrh6NHDaExo4fRKc5vuXfPTqrLEeiXL1+ibt36uGht7VYlDgBC tDoUUPgdGgXBPUjfgwTu9+/fp0eP/qTtHFkNZiVXgmhz1Hv58iUhYOfWzeuUMkUq9gX9jP1RI9Lm TevJz89PBRm1atnQVVd294oW+Z66dP6BUzvtorNnz6hoeUTTlyhRRimldeo1VhHkrVo0UCxCwKx1 q8bMhtQrSOPXrddIKeEtOEk8FNdnvNV+hbFHsvgrVy6r+S1buoi35ZPQqZPH7eZrpcAKLs4wRf9J k6VQw8yfP4utwOeVy4QqkA9BIBgIIPXXhPGjqF/fHrRw4Vz1++you23bNqvfQysvkv36dqc2/Pvo SsICE5ur+Tu797Guy9l6pTzsIRCVA3ijGOJAtBWEZyNUdM4lHY7/b4uEPQQ8Vj6xxJmzF1HRYiVZ 2RlBpUrkpxrVK6hUSrPnLqX/5c2voxAhfASl2OkFfBIxYmAaH9yDOKpToUJVtYUOxbK6aXu9c5de VJv9EuEXmi1LGsqUITm19W1Gj3nbXOtPHTm1j1GgYDZvWpdSp0xABfJ/yxbDpNSrz2B2E/CiXr0H 0rFjRylr5tRUrUpZqlylBqdoiqNb7/S5mvrU+m/YsCnt3rWdqlcrT8WK5KERwweq6PxhIwL9UmGl RQqk6xy1DxYhYIYcpYjgD8r4CMCaNWcp+T/zp5LF81Ha1IkoP0fZwxodibfkIffv31V+oRHfpk3S 5mo8AhP8OBIr83KGKfpDsBeU76VLFlDBAjn5BSXoUfiO5idlnxYCeGnE72bVyqVpBbvkgMQAKdY2 bVhrBwReXJs0qqUYtlauXGJ3PygFZiY25PYNSwxezuZrXldQsJE2gkBoIhCZM7DEadKAIpiyz3j7 NqeYkyfQv29TKYbmHKTvkEcgHAcJBUYJve37qX8APX/xxtJICMhBGqR48RJwlHRMuzbYikf+SwQL GeXFixdqSxplzupgS/rvv/+mqFGjGJvq55j29evXWXkK3Ho2BjkZ+9cb8MmrVwHK4okUR2a/VCSu v3PnFiVLnkIpnahrHNtZn8b+77KbwKuAAHYVSK7mZbynnWObHf6fCEAySlDH93/qrxTNhAkTUyyv WHqXFcoVU76mrnKVYo1RokS2CRDTO3h74m5erjBFF3/88ZBeMyZwmRD5MBCIET3w99Hq7/mHMGtf pq7duXMbv/guVm4zmBP+Bvz99z92v2vlyxbhDBnxuf5WQlBc9x59XS6hfr1qypUHKdCciXmsNbyz 0bJ5A9rHbGZpvkzrrNkHU+5svuZ1fTATDuWJJEoQg+75eRacGcpTku6dIBCO/4ck+D4HvUmXlv7k 1IKQKEzL/Vmj2vRo5AR6Vauuk5ZS/CEhECd2NIoa5V3si2Ozl8UZw6/PWQQ3ughkD3o3mNYtfCE1 cVYHPpRmP0qtDY5QNlOkSGEs0s+N/euFfAJl0tk/CihhxrUYFU/04axPY/9WFCxE8DuSoI4PhdOo dKLvw4cP0sWLvzLF5wFHQ+ll5jXqNwwn7ublClN0AyutiCAQHATAorVu3SpC+jT4F2uCvwGBfz+0 EmJL+0I6f/E87d49Rymf7+64P8ML77JlC1kRvUbZvvmWivHujvZSe/DAOyY2bP1bZfDav2+PGtgV yxsquGJtUx3wB8gbdrECjgwViRN/TuF49wg7FOXKVVJVMC9HLGmu5mtcl1WGuZBmVtPWJ0dBwBEC //L/EP8f2pF3v54UhV/6AkpXIC8+D+DdNVE8HSEWNsqCpXyGjSV+erN8yFSko8dMcaqcf3qIyIrD MgL79u5WKdYqVQpMjeZsLfB9Hja0HzVr2srjQLxnz59RiWL/o2fsyhI5chQaN3YEk1BUpkmTZ6vh jExs69ausMzgZYXlzR1rGyYA/9buXdtxDuLcit3t3Llf1Itdmi/TKeXTFRuZq/ka13WAFWV3DHOh xazm7JlKuSAABF40bU0xFs0nr4F96AXHNUTgXc9HU2YJOGEYgSD5fIbh9X4SUy/LlpASJct8EmuV RX78CFy+fEFZIOfMnkp5cmeltGm/oP99n40G9O9pQywxbEg/diOJohjNPEUFGTTy/C8/HfnpLO0/ eIKaNmtNa1avYMYv+614Txm83LG8WWFtG8l+5NVr1KHlKzbS9p2HqFKlqiqIcfWaLWqprtjIrM7X HcNcaDGrefqspP4niAC71z0ZMJQi3rxBsUYMphdVq9Ff2bJ/gkB8PEsW5fPjeZayEkHgo0TA399f +XdevnyR2rbrQpMmzaJ8+QvRpIljOOtGII3r5UsXmd52JvXmIEKzj7kGyuvXb3jL+oX+A39HTcDE hny32jZ7y1bt1C2QXARXXLG8wefdHWsb5g3XA6RY0yQXux+gDIFYEHdsZFo7V0d3DHMhyazmah5y TxBwhMCbLNnon2heFI5vvnnLXuionpSFDQRk2z1sPCeZpSDwySIQ6W3Ghjlzl+l+4KCmPXH8KG3m /Lmdu/SkHj060Pff56XiJUo7xakAZ4S4du03/T5y69ap20hdm5nYEiRIoDJu3L9/T68f1BNz30aW tzdv3rhlbQP1L2iHVy5fTIUKFqW48eLRsqULVZlVNjKrc3fFMBeSzGpW5yP1BAENgVicLpEihqeA b3JQrNHD6VXlmvSvIchWqyfHsIGAKJ9h4znJLAWBTxaBzz6Lq9b+xx8PbLJEJP48CZ3jvLpgETuw f69i/cqV812ieCh2CxfMoQ3r19DW7Qdp0ZK15O//jvQgZao0LjF9/TpAMba5rBSMm2B5s8LaBgtt VKa8vXf3jkqphiG/TJueJk6aqY/ujo1Mr+jmxBXDXEgyq7mZhtwWBGwQiMC5saMvXkRPO3engKLF KX7R/BSDU609GzjMpp5chB0ERPkMO89KZioIfJIIfJ05q1o3Ao+qVqupY4CtdqRGA6Xv4CGjOG3b X/o9nPTu1ZWy8FYdrKHRY0TndHApbO4bL/788w+VFkzLzgBfT2xpf+kkjVJIMXhZYW27yNH7J08c o917fiLv2LHZNSA8JUwYSHOMNVyzwEZmdb6YjzOGuffBrGZ8JnIuCGgIeHfrQH8nTUIvWrXlPEuR 6aVPZYo5eza9rN+Y/nbyO6q1leOHiUCYUT6RBgWO+5kzZ3OYU9QRvOY25mtHbaRMEBAEPiwEChQo QqClHcX+nUmZsCFhwkQ0ZfJYZs26Qr37DlZ+mvXqN7GbNFiQvvo6Czm6Z66MfLSVmHK3+4/9mGDi M2Ys81XR5D5V3im7xjZGBq8YMWIqcodUqVIbq1g+B2vbrJlTKDMrymXL+Sif1WPHfqJrv1+lJhy5 j7RKyAtctWoZSpMmHUWLFpU+ixOXvsudl6rVqG3Dkla8RFn2Bb1D7du2sBnfk/mCYa5L57aK3hhB SJqAWW3G9IkEZrX+A0cwlXJause5jeH6ULJUOZ7bO59UrY0cBYHgIhCVMz1EYaa+P2HpZ8UT8rRn f4q6aQt5de9Aj5avD+4Q0v4/QMDjgCPwIM+dM93uBwnWjYLISKTtANvPjh1bVTJ5432cW6mjtbl6 9RJV8SnFTDnbtSK7I1KWgCbvzFsmBHMb87W5vl2HUhBmEcBW5ZLFC2jVyqUO1wBqVqSvAUsNqFqx detIYBFbtHCeiqweNXKwojM11rPaj7GNnHuGAHJ5TpuxgCKz76dPxRIc6Z6VdvLflDFjp1LRoiWc dgYGrggR7PMMmxuAwax4iTKU49tc1KhBDapQrii94LRNSGgf8y17ipmJzSqDl7kdxjazvLllbWNW uHjx4lPq1Gk5Ij8fc9B/rb6vnTq2pl4/drbEkuZsvo7m54xhzgqzmhlbuRYEgoUAk9R4DRlAATly UgC/FGnyL7+MPWvWjKKyu01k/hEJewh4zHDUk//Y4S09Viwvm9WOHjOZ337LqrJ5c2dQdzaTf85b OHH5j+YZ5h9HgMD0mYv0SFQrdYwDXGA6ykIFctG06fOoTNmKxlv6ORImV61ShoaPmEA1mfXA3MZ8 ba6vdyQn7x0BvKgkSJCQLT+BCbODMwE853Zs+TnNfkKZM2ehLdsO2HS3Z/cOasOMOUjLkyx5SqY6 PceBLJFp9dptNkQDSGzerUs7ZVlLmy4DPecckAGvX9OevT+p/qz2YzP4B3ARFhmONNgQ4W3edtbu mY9WGLzQBjsiWsJ6vGy84u32z01kEM6Y2NwxeDlr54gxDS9MjljbkFtz7JhhdOL0FV0Zxrzh53mP A6K076M7NjK0Mc/X2fyAiSuGOWfMahgjLIgwHIWFp/R2jpyhghliiNhH2k74JZGEXtMOlg+xINgM R6DLREoO5JpzJLCMduvaXm11DRo8UlWB9ak1WyTBHlK7dn3eLnNfx1Hf7spgFfj9+h+6ghvS9d31 J/eDjsD8+bMpDaeSCa7yuXHDGvrBtxmV4m1A0HqaBf9UsaWaPEVKWrFys2K9gs9c6ZL5qW+fbjRn bqCl9MrlS9SxfSsqwNHFSDSuMemgPcRqP+bx5Tp4CJhpaV31ZoXBC+2NTGpacJO5X2dMbJqPqLm+ du2snSPGNCjAKVKk0JrqRyiBz549Uzz25StUVpS4p/jFCi9Z+QsU1uu5YyNDRfN8nc3PHcOcI2Y1 fSJyIgiEJAIGRkS7bkXxtIMkrBSEuM/n4kVz+R91ROU7pYFQyacaDeXItPVrVyrl00odra2jI/7o ruO+8I+iRMmyyh8M9cBwsmzJfOV/BD8pd+Ks/hVmUDh4YI/Ko5eGt7qK8ZackbveKmWeNj4sZE+e PqHy5X20InU8dOgAPXzop9PjuaPYe/DwAW3ZtI4DDH5X23BFi5a0oQvV5pUufUaaN3e64q9v3KSl WsdaxsuPrSSZvsrM4/noypTNhPjC3Rio747mD4rZzh1b6Ny5M/xSGpMpEfNQVicJgf39n9FaZox5 xlHIt2/fpAUcnRyD/6BUrBi4xeJJX5hb7Nif0dJl6yh7jlxUvmxRpi0MzIOIexDQjt68eZPate+u FE+U4R9+4cLFlO/a3/xyheCMqVPH8z/5qDR23FQbrDRFxWo/6F9EEAgOAg0bt6Djx45S+3YtCFvt 0aJFVxSbpUqXowEDA1/wg9O/tBUEBAFB4H0jEOLK5+nTJ9jxPK3N9hAWlS5det7e/FWtz0odZ0As YeXyp6OHOeFyGnbI/53GjB5GCxauVMrNrZvX6ccendT2rbOteWO/jupPmzaRBg/sTQnZpwR+VjNn TaVhwwfQ3HnLKD0rdRArlHnGcfbv30NTp4ynnN9+R0b+93Ztm6tcfeBmdkexB0tH1cqleW2JKBkH XVzlYIuhzOgCS12BgkX0eT19+pQDBW7RS96qgJU6b96CVLFCcW6TjJX05LSWuXH9WRF2FIRhZQx3 NH/w/a1frxr9zsESSAfz558PCYEfCJzo22+IERZ1fv/+XZo0YRRvB/5Bz/nlAefeseMo5dPTvtAh rN+u5NGff6rbMWPGsKkGhX3FiiX8nfqNfevS0GF+MUBfWh5Fm8p8YbUfczu5FgQ8RQB+p3PnL+ff W3+6fecmhedod7iLWLXsejqe1BcEBAFBILQRcOBE4XpIbA1duXKJMn+VinJ8k56tS0VoMXOuamwh fzx8qJQHcy9xODrzKf/xhFipY26vXV84/yut37CLtmzdTzt3H2E3kPA0aFBv7XawjgiAGsABKNVr 1KUjR3+hDRt30bZtByng1StWajva9O2OMs9YuUbNekoRXM5JojX5mS0ZoPSrXDmQr9odxR62y2bO WkwHDp3kfIVraP+Bk6zIfk7gZjbKkcMHKEf2nOwfdplOnLrMlsTZypK4mfGaMWshHT56ljmr3zlu G9taGcMdzV/v3t2UpXXTln20cdNuOnzkF6V4Tmel/vDhg8bh1DkiZA8dOcPb4KkoT5786nzzlkAH ck/7suvcQQHGw3dm21Zb5hotTc/Tt4FHSEb++NEjqlalLH2VMYX6vlfkaGgo6BCr/TiYghQJAkFC AFvdeAFOyy/yongGCUJpJAgIAh8IAh4rn3XqNOScemNo4KAR1Kp1O4rAkZgd2rekkSMGqSW9fPmC IvG2u1kQ3IF7ECt1zO21627d+lC69BnU5RccFFCYA5mOHjlE2C4NrixePE/xJXfv0U/vCluyUNYO HdyvaPm0G1A+wJkMnyko5Eg18pQtikhzYhbUzcasDHAV0GTViqVsWY3HUbZlVSYAdxR7SZMmo7z5 CmjNlV9runQZOfH0Xb0MJ5+zQjpy9GS1dYwtYrgmPHjgpytbKANjiiNxN4Y7mj+4DWzauJYqMu80 1qxJx04/quCeDetXa0VujyHZl3EwWJ5r1qqnrJylSxWkZk3rUdHC39MwdguBRIwUiRORP1MvC3Dv yM5RluMnTqcfew6g+/xs69b24ef8VFmw3fVjHFfOBQFBQBAQBAQBQSAQAXst0Q0yUPw05Q9V6zdo SiWK5WUfw5nUsVMPFQX/7Pkzu14QQYr8eRBEyrurY9fB24IoUaPY3ErBFjMwmTzwu29THpQLWLsS cPJmo38n+sE2LAT3EWwFcUWZpyqYPnzY7xUuARcvnFeWC3BGF2GfTSiDCMB6zVHUE8aPVNvzWtM3 b14rJejFi2dKYdy3dxfNnTNDzePZs6f06MkTSmKKyvX2jqMCErQ+mjVvQ7CGNqhfnTJl+pqaN/cl nyqB1latjvHoagxwZrui+cPasNWfNm3gy4HWL/AEXeGtWze0IrdH5DgMqb7Mgw0bPo4KciARrNdI JA4lEvzhQwb3VW4NkSMH5pKDEg3qRk28vb0Vjrt3b1f+u+760drJURAQBAQBQUAQEATeIeCx8vmu aeAZrH4ZWak5yzR3sFbFZn+9a9d/N1ejO3dvKyscblipY9eBk4KAgFfqDqx5jx8/clLLWjHy771h JdAsL1hBgWjKs/m+8Rpbuo6kMierHjyoj4r4L1S4uErgXLVabVXVCsXels0bqHGjWuwSUIf9NRsr 14ZBA3pxgJCfo+H0MkTVLuUkvEfYOjx54mhq06YJ3eLAnh/adtLraCfuxnBH8werIcQc5IOyVxx5 7s1MNFYlJPtyNCbSgmmpwXC/A0e2w2qsMceANQdpaYyCFx3IE8P3zF0/xvZyLggIAoKAICAICAKc OSskQMD2ZLLkyZXF7bvc/1O+jIgY1wTblGd+OU2FOKIYYqWO1tZ8xFhGOca+k9h+dxYYYqzr7hwW zjt37ihLpLHu4UP7VRCTlQh6YzvjuZeXF+XPX5g2cCqgVSuXsI9jCo4C/15VMVPsJeeAIu0HFkPI mjXLeZ1f0IiREyhf/kKKNjC6B2kmMBaCFnJx5Pk2tro6EndjaDR/ixavYX/SS3SS8w7u3fczfcUR 9JDkHAQBZffo0UM23SM6/oGfH331libR5ubbC0SYPzdYzIPTl6P+XZUhwn/TxnWsjJbXqyGg7cTx n/VrnGj+nmnZ3cGROOrHUT0pEwQEAUFAEBAEPmUEPFI+Hz36k5oztdr27VvoOgfLnObk8b5tmqpk 3s2atVE4Vq1Wi2KyotW6VUOVHgSKR9PGtSkSM43UrtvIch1nD2XC+FGKlebcuV9o9KihdIDZDWAN DAmBCwHmDvo4WAp/58hnMDRt37aZmrfwDfYQ1XieCDJCxHmZMraJ8kGxt559IsG2A9YcYA2cEagD iRs3Pm9b31JlYOMZP26kYnlxNykw+KAfbC8joAoR/infWvDMbd2NAeVbo/lr1bIRWwtbkC8nawcD EHxu4f8Kay4UOczvGufPPMi+sq1aNlRWRfgLOxP0i2eKxP/APqh9wfqN9vh5xknhsW6cH+UMCVpQ 3Px5M9VYiKaHH2oFTsmEl4O27Trr06tSpYaibwR++K4Dw+HD+qmsCtpLg5V+9A7lRBAQBAQBQUAQ EAQUAh5tu0eNGk0pRqCg06KDwWKE4CMobhBYIefMWapy0pUtU0QF4yDlzoKFq5Q1z2od1ZnhA+lF ICNHTlSpjyZPGstBN5GpWvXa5PtDoNIAqjhIhAiBy/L0GgoQ5t6lky/zPBdXfSHd0o/MI2tUPh1R 0pkp81Rj0wcsv+CovnXrpoqoN94GxR78PhH40qtnF3UL2/z1GzRR523bd6Hjx49SvTpVFKbZs3/L vor16djPR/RuHM8rIjVvWlcpYaiYM2du6tVnsN7GeOJuDASXAY+Y7LOLNETw40X6LOQeRE5PfA96 9R7E3403NG7scOVmgJyv33zzLc2es8yldbpVmw7UhN0KqnA6KWx/HztxMUh9rVm9XLFrGdelPcuf j59X38+FC+co7mrUicSuAvnyF6T+A0baJOBu0LAZZ3W4rChi8V1DwBwCvkaMnIRmShYudN9PYE35 FAQEAUFAEBAEBAENAY/pNdEQ1HDIS/lZ3Li6H6fWofEInzkE5sCq5Eys1NHagi4PKUZgZUM+xi++ SGqXcsRMW+fptTYWrIvPmVXETLOH+84o6cxjaX0ZjyVL5Cc2wdHmrfuMxfq5M4o9rQLoBaF0I4od dZGEHYFAEGfzAm6weMaLH1/522p9OTs6G8MqzR/6xTO6eeOGspRaTQuDtSAoKXHiL2yea1D6crY2 rRxrRF7RZMlSqKAvrdx8BHbIm5o0aXKH9az2Y+73v7wOy/Sa/yVuMvbHg4DQa348z1JWEjYQCDa9 JpYJv740X6Z1u2IzlZujBlbqaO00JQb+gVoEunZPO5pp6zy91vpBAJOzlETYEmb7qlZVP5rH0m+8 PYELAvjGe/d1bHlENQRwpWB/UGdipBdEXU3xRH1n8wJuVp6XNqazMazS/KEfPCNX69DGMh4R+Z8y ZSpjkToPSl92nZgKjGs03bK5BHapUqW2KTNeWO3H2EbOBQFBQBAQBASBTxmBIFk+P2XAgrP2rp3b 0tKlC+j4yYsuLcbBGSM024KOtFXz+rRz5zZ2bYhgQ/M3fMREuxRVoTkX6TvoCIjlM+jYScuPAwGx fH4cz1FWEXYQMFs+Rfl8j88Ovp7YKkcy97AsQvMXlp8ekSifYfv5yeyDj4Aon8HHUHoQBDxBwKx8 ehRw5MlAUtceAQQbfQyiaP68HKcb+hjWJ2sQBAQBQUAQEAQEgdBDIDCEPPT6l54FAUFAEBAEBAFB QBAQBAQBHQFRPnUo5EQQEAQEAUFAEBAEBAFBILQREOUztBGW/gUBQUAQEAQEAUFAEBAEdATsAo40 Fhi9hpwIAoKAICAICAKCgCAgCAgCwUAA6SE1sQs4Mt7UKslREBAEBAFBQBAQBAQBQUAQCAkEZNs9 JFCUPgQBQUAQEAQEAUFAEBAELCEgyqclmKSSICAICAKCgCAgCAgCgkBIICDKZ0igKH0IAoKAICAI CAKCgCAgCFhCQJRPSzBJJUFAEBAEBAFBQBAQBASBkEBAlM+QQFH6EAQEAUFAEBAEBAFBQBCwhMD/ Ady6njPd53s5AAAAAElFTkSuQmCC --_004_6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47irsmsx105gerc_-- From nobody Thu Jul 5 23:02:18 2018 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 94990130DD0 for ; Thu, 5 Jul 2018 23:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHYvlz3XNNRM for ; Thu, 5 Jul 2018 23:02:14 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E00130934 for ; Thu, 5 Jul 2018 23:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6662AJX017262; Fri, 6 Jul 2018 08:02:10 +0200 (CEST) Received: from [192.168.217.102] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41MPJL1NtYzDX6V; Fri, 6 Jul 2018 08:02:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> Date: Fri, 6 Jul 2018 08:02:09 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 552549727.559808-dd3a87be7acfddc4aec8402d02c4c78c Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 06:02:17 -0000 Hi Laurence, > On Jul 5, 2018, at 23:23, Laurence Lundblade = wrote: >=20 > You=E2=80=99ll probably say I have way too much time on my hands, but = there=E2=80=99s a tag 1 implementor FAQ below. I like the idea of collecting FAQs like that. I don=E2=80=99t think = that the normative document (RFC7049bis) should contain all of that = material. =20 I=E2=80=99m wondering what a good place to collect that material would = be; a Wiki may be a good way to start it, but the consensus vetting = inherent in publishing an RFC may actually be useful here. =20 This is a bit along the line of the idea of doing a =E2=80=9Ccommonly = used tags=E2=80=9D RFC, which would contain information about both = standardized and otherwise registered tags. Maybe that is a good thing to start now and complete after RFC7049bis is = done. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 5 23:46:35 2018 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 0D2C8130E1F for ; Thu, 5 Jul 2018 23:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvp5XVkr0egO for ; Thu, 5 Jul 2018 23:46:33 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61B6130DE2 for ; Thu, 5 Jul 2018 23:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w666kU1x019701; Fri, 6 Jul 2018 08:46:30 +0200 (CEST) Received: from [192.168.217.102] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41MQHT65plzDX6q; Fri, 6 Jul 2018 08:46:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> Date: Fri, 6 Jul 2018 08:46:29 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 552552386.944675-8b646235c38e59ea6d853c959264c442 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 06:46:35 -0000 On Jul 5, 2018, at 23:23, Laurence Lundblade = wrote: >=20 > microsecond time If I am not mistaken, the range for which a binary64 float gives = microsecond resolution is approximately 1697-10-18 to 2242-03-16. Obviously, Unix (=E2=80=9CPosix=E2=80=9D) time is somewhat questionable = before 1972 (and certainly before 1958), and it does not give = microsecond resolution during (added) leap seconds. If better resolution is important, and/or a monotonic scale is = desirable, tag 1001 is useful and probably should be mentioned in that = FAQ as an alternative. (We haven=E2=80=99t done the work to actually = give 1001 a monotonic time scale, or any way to go beyond civil time =E2=80= =94 doing that would probably usefully include a discussion of proleptic = time scales as well.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 6 09:01:45 2018 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 4039F130DED for ; Fri, 6 Jul 2018 09:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wP7_PrjLSI_V for ; Fri, 6 Jul 2018 09:01:39 -0700 (PDT) Received: from p3plsmtpa08-08.prod.phx3.secureserver.net (p3plsmtpa08-08.prod.phx3.secureserver.net [173.201.193.109]) (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 2A5F51310A6 for ; Fri, 6 Jul 2018 09:01:37 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id bTAuf7MIpTeHsbTAuf9SNQ; Fri, 06 Jul 2018 09:01:36 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Laurence Lundblade In-Reply-To: Date: Fri, 6 Jul 2018 09:01:35 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfOgD8pOWYHxQ0k5t05v/wTr5mLJRXncZ5V7LqGOHw3eKAfM4mJNEBFSbth4Rl8jHJP2pXfG0mxHcL0uRvxTeRl3oNJzbDuVaZjO+afFyQ/aW/Rb61mqi JvD9Prx2ZE3231PxAUAkv2fYveQ0dld6ixHxKPYG1EAjlfhTE0RvX9STkvks/D1ai+5BcvIQ+Fu47w== Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:01:43 -0000 Hi Carsten, Agreed that it doesn=E2=80=99t belong in the RFC. Maybe on cbor.io? I = have a site I could publish it on too. The vetting by discussion here = is probably enough. After some review here, I=E2=80=99ll update it with any needed fixes = plus some links to references I found useful. Glad you like it (and didn=E2=80=99t find too many errors). :-) LL > On Jul 5, 2018, at 11:02 PM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 >> On Jul 5, 2018, at 23:23, Laurence Lundblade = wrote: >>=20 >> You=E2=80=99ll probably say I have way too much time on my hands, but = there=E2=80=99s a tag 1 implementor FAQ below. >=20 > I like the idea of collecting FAQs like that. I don=E2=80=99t think = that the normative document (RFC7049bis) should contain all of that = material. =20 >=20 > I=E2=80=99m wondering what a good place to collect that material would = be; a Wiki may be a good way to start it, but the consensus vetting = inherent in publishing an RFC may actually be useful here. =20 >=20 > This is a bit along the line of the idea of doing a =E2=80=9Ccommonly = used tags=E2=80=9D RFC, which would contain information about both = standardized and otherwise registered tags. >=20 > Maybe that is a good thing to start now and complete after RFC7049bis = is done. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Jul 6 09:20:12 2018 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 63186130EC2 for ; Fri, 6 Jul 2018 09:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CIfF_Aum-GH2 for ; Fri, 6 Jul 2018 09:20:08 -0700 (PDT) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.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 4C4F4130E84 for ; Fri, 6 Jul 2018 09:20:08 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id bTSofoahYdgB9bTSofXVm6; Fri, 06 Jul 2018 09:20:07 -0700 From: Laurence Lundblade Message-Id: <2BA55353-6A8A-451D-AB7B-6868F3C1DEB3@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B5DEB86B-7004-46E7-B569-4DAE9093B6F0" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 6 Jul 2018 09:20:06 -0700 In-Reply-To: <6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47@irsmsx105.ger.corp.intel.com> Cc: Carsten Bormann , "cbor@ietf.org" To: "Macieira, Thiago" References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <9350E004-7AE6-4D5D-99E9-3332B3386749@tzi.org> <5B44DD0E-6518-49FF-ADA0-8F42D6377094@island-resort.com> <6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47@irsmsx105.ger.corp.intel.com> X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfBbBDOvT93HbNoiZrRgdnxcAkJzrHALUx/AYMnOiX9X1G8uYrOl8GkGqGx3pVXIa3MiN6dritOiWHFavidR30qDnNpGQUPJCat1I2liOLv4z28pZKXFh 7dqpSvt2Xqszg8Tn/thIB0XnVsbkakvilsOZ2txygALP8tzuUCtuvSErL4du4nYBkUQzrFoGYBa8sTKIvIdNC7G3FMCK2/ObpkYQzrnijyZSRyT60M/5PuHr Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:20:12 -0000 --Apple-Mail=_B5DEB86B-7004-46E7-B569-4DAE9093B6F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thiago, Correct me if I=E2=80=99m wrong, but it is OK to pick and choose bits of = CBOR to implement. So, for a chip like the AtMega32U4 = , RAM is so tight = (2.5KB) that you might not use or want 64-bit unsigned for anything. = It=E2=80=99s also an 8-bit CPU so just moving 64-bit quantities around, = byte-swapping them and such is going to use a lot of instructions.=20 As I understand the CBOR philosophy, it is a design goal to allow = designs of protocols that explicitly don=E2=80=99t use parts of CBOR and = to even error out on valid CBOR because it is outside of what is allowed = for the protocol. So a protocol designed for super tiny devices like the = AtMega could disallow unsigned 64 entirely and error out if it receives = them. The issue with negative is less about the integer encoding. It=E2=80=99s = about the lack of a proper standard for time before 1970. Also, you = might save some object code by not implementing negative dates as the = need for them will be rare. LL > On Jul 5, 2018, at 5:10 PM, Macieira, Thiago = wrote: >=20 > Hello Laurence >=20 > I don't see why you need to talk about the unsigned width. It's = encoded as a CBOR unsigned number (major type 0) and therefore uses as = many bits as necessary. That is, it has needed 32 bits to encode since = the second day of the epoch and will continue to need only that much = until 2106. If someone wishes to represent dates beyond that, they'll = need 64-bit width. But if someone wishes to encode only the epoch = itself, they need only 1 byte. >=20 > Similarly for negative: any date prior to 1970 will require negative = numbers. >=20 > So if you want to implement the minimum, you implement CBOR unsigned = and negative, of all widths. Any implementation not supporting 64-bit = width integers is not compliant. They may be able to get away with it, = but if they fail to parse wider data, the bug is in them, not the = sender. >=20 > PS: double has 53 bits of resolution, not 52. > From: CBOR [cbor-bounces@ietf.org] on behalf of Laurence Lundblade = [lgl@island-resort.com] > Sent: Thursday, July 05, 2018 14:23 > To: Carsten Bormann > Cc: cbor@ietf.org > Subject: Re: [Cbor] PR for improving epoch time (tag 1) >=20 > Hi Carsten, >=20 > I=E2=80=99m definitely after tightening up tag 1 here (and exploring = as an example around canonicalization, variation and options in CBOR). = I=E2=80=99m not a time geek, nor do I have any use cases other than tag = 1. I think tag 1 time probably covers the vast majority of use cases for = time in CBOR protocols. >=20 > I=E2=80=99ve updated the PR = so floating point is no = longer removed, but still discourage its use unless greater than 1 = second precision is needed. The interop problems I see with floating = point are: > - Small CPUs like ARM Cortex M0 and ATmega16/32U4 do not support it > - Floating-point is extra work for a CBOR implementor (It was for me = anyway) >=20 > There should be as few choices for the implementor as possible and = those there are should be clear. So the choices in the PR = are mostly a) 64 or 32-bit = integer support, b) support negative time (to sort your Jimi Hendrix = albums), c) support double if you need microsecond time. >=20 > I do think there should be clear requirements for each tag, maybe even = canonicalization requirements per tag, especially for a tag that will be = widely implemented and used like tag 1 and especially for something as = problematic as time. >=20 > You=E2=80=99ll probably say I have way too much time on my hands, but = there=E2=80=99s a tag 1 implementor FAQ below. >=20 > LL >=20 >=20 >=20 > Tag 1 Implementator=E2=80=99s FAQ >=20 > >=20 >=20 > Q: I just want to implement the minimum, what should I do? > A: You should support 64-bit unsigned encoding. This will cover just = about every use case because it works from 1970 until over 500 billion = years in the future and 1 second resolution is enough for most human = activity. Note that time values up to 2106 will be encoded as 32-bit = integers even though 64-bit integers are supported because only 32-bits = are needed to count seconds up to the year 2106. >=20 > Q: I=E2=80=99m implementing on an 8-bit CPU and 64-bit integers are = really a problem. > A: You can support just 32-bit integers in that case, but they will = stop working in 2106. >=20 > Q: Why 2106 and not 2038?=20 > A: Because CBOR encodes positive and negative integers with different = major types and thus is able to use the full 32-bits for positive = integers. >=20 > Q: What if I need time values before 1970?=20 > A: Implement 64 or 32-bit negative time values, but note that there is = no clear standard for this as POSIX and UTC time are not defined for = this time period. If your implementation assumes every days is 86,400 = seconds and follow the rules for leap years, you should have accuracy to = within hours, if not minutes. >=20 > Q: Is Tag 1 better than Tag 0 for time values? > A: In a lot of ways it is, because it is just a simple integer. It = takes up a lot less space. It is a lot simpler to parse. Most OS=E2=80=99s= have the ability to turn POSIX time into a structure of month, day, = year, hour, minute and second. Note however that POSIX time has a = discontinuity of about once every year for leap second adjustment. >=20 > Q: What is a leap second? > A: It actually takes the earth about 1 year and 1 second to revolve = around the sun, so 1 extra second has to be added almost every year. UTC = Time handles this by counting the seconds from 0-60 (not 0-59) in the = last minute of the year. This standard uses POSIX time which can be said = to handle this by the clock stopping for 1 second in the last minute of = the year.=20 >=20 > Q: Do I have to implement floating point time? > A: No. There are not many use cases that need it. However for maximal = interoperability, it is good to support it. >=20 > Q: When should I use floating point? > A: Only if you need time resolution greater than one second. There is = no benefit otherwise. 64-bit time can represent time +/-500 billion = years in the same number of bits, so floating point time is unnecessary = for very large times scales. >=20 > Q: What resolution to I get with floating point? > A: It varies over the years. For 1970 to 1971 you get almost = nanosecond accuracy. For the current century, 2000-2099, you get = microsecond accuracy. 285 million years from now, it will be less than = a second and the 64-bit unsigned representation will have more = resolution. This is because a double only has 52 bits of resolution. >=20 > Q: Should I implement single or double floating point? > A: If you are going to use floating point you should always implement = double. Single has no advantage over 32-bit integers. It provides less = range and less precision. It has only 23 bits of resolution. It is of = course good to support decoding of single in case some one sends you = one, but there no point to ever sending a tag 1 encoded time value as a = single. >=20 > Q: Can I disallow floating point time in the definition of my = protocol? > A: Yes. This is a good idea if you do not need resolution less than = one second. It will make implementations simpler and more compact. Note = that while most CPUs do support IEEE 754 floating point, particularly = small ones do not. >=20 > Q: What I=E2=80=99m transmitting thousands of time stamps and space is = a problem? > A: If you want to maintain 1 second resolution, there is really no = more compact way to transmit time than tag 1 32-bit or 64-bit integer. = If you wish reduce resolution, use a different time, perhaps one that = counts days rather than seconds.=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Jul 2, 2018, at 12:10 PM, Carsten Bormann > wrote: >>=20 >> Hi Laurence, >>=20 >> the representation of time is indeed one of those eternal issues in = representation formats. >>=20 >> Tag 1 is relatively well-defined as it is, and I don=E2=80=99t think = we want to change that. >> Instead, new tags have been defined for time (and there, of course, = also has been tag 0). >>=20 >> Not all tags need to be defined in the CBOR base document. >> In particular, in this round we are aiming to collect the stable = parts of CBOR, as opposed to putting in more bells and whistles. >> We are *not* defining a new version of CBOR (there are no versions in = CBOR). >>=20 >> New bells and whistles can be added by just registering tags. >> The set of registered tags can at any time be examined at: >>=20 >> https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml = >>=20 >> Looking for =E2=80=9Ctime=E2=80=9D, we see (apart from 0 and 1): >>=20 >> 1001 map >> extended time [draft-bormann-cbor-time-tag-01] >>=20 >> This tag has been registered a while ago and already has been = implemented in some environments that care about precise time (e.g., = Haskell with its picosecond-based time). >>=20 >> On to the specific changes that you propose: >>=20 >> =E2=80=94 getting rid of floating point time =E2=80=94 I would expect = that is in active use, but I haven=E2=80=99t done a survey. It = definitely is allowed by RFC 8392 (which uses Tag 1 in an indirect way). = Floating point time has the weird property that its resolution gets = lower the further away you get from the epoch. But otherwise, it is = fine. Currently, of the 53 bits of resolution of a binary64, 31 bits = are taken for the integer part, so 22 bits remain for the fractional = part. That will change to 32+21 in 2038 =E2=80=94 a date that most = people who work with Posix times are aware of, as the integer time_t no = longer will fit in a signed 32-bit int then. So I don=E2=80=99t see any = deadly interoperability problems that would stop us from continuing to = support floating point valuess in tag 1. Any specific application can = be more selective, if desired. >>=20 >> =E2=80=94 being more explicit about negative values (int or float). = Good point. >>=20 >> - requiring support for =E2=80=9Cpositive=E2=80=9D (I think you mean = unsigned) integer values. Just as an application can rule out floats in = its usage of Tag 1, it could do so for integers. A generic CBOR = implementation that doesn=E2=80=99t support integer values here could be = considered not so bright, though. (CBOR is more about interoperability = than about conformance, anyway.) >>=20 >> =E2=80=94 comments about serialization (encoding). I don=E2=80=99t = think a Tag should define that level of requirement. If an application = wants to use minimal-size encoding, so be it, but that=E2=80=99s none of = the business of a Tag. >>=20 >> So, in summary, I=E2=80=99d say let=E2=80=99s pick a good way to = handle negative numbers (being aware that there is no really good way). = Probably MJD-based interpretations. But let=E2=80=99s talk to = astronomers here=E2=80=A6 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Jul 2, 2018, at 20:29, Laurence Lundblade = wrote: >>>=20 >>> I think that the more we can reduce implementation / encoding = options and variability in CBOR the better. Seems this is also what a = lot of the drive for canonicalization is about. >>>=20 >>> Here is a PR for new text for epoch time (tag 1). =20 >>>=20 >>> I don=E2=80=99t know what the philosophy is for compatibility with = RFC 7049. This proposal breaks it. Maybe it should be a different tag = value or such because of that. >>>=20 >>> The big break is disallowing floating point values because you can = do better in a number of ways by defining a new tag for time expressed = in micro or nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here). >>>=20 >>> The general decoder implementor and protocol designer is left with = only two choices: >>> - Support 64-bit time values or not >>> - Support negative time values or not >>>=20 >>> The protocol designer should of course make a call on these choices = so there aren=E2=80=99t interop problems. >>>=20 >>> There=E2=80=99s more detailed rationale in the PR comments. >>>=20 >>> I=E2=80=99m curious what you think. :-) >>>=20 >>> LL >>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 --Apple-Mail=_B5DEB86B-7004-46E7-B569-4DAE9093B6F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Thiago,

Correct me if I=E2=80=99m wrong, but it is OK to pick and = choose bits of CBOR to implement. So, for a chip like the AtMega32U4, RAM is so tight (2.5KB) that you might = not use or want 64-bit unsigned for anything. It=E2=80=99s also an 8-bit = CPU so just moving 64-bit quantities around, byte-swapping them and such = is going to use a lot of instructions. 

As I understand the CBOR philosophy, it = is a design goal to allow designs of protocols that explicitly don=E2=80=99= t use parts of CBOR and to even error out on valid CBOR because it is = outside of what is allowed for the protocol. So a protocol designed for = super tiny devices like the AtMega could disallow unsigned 64 entirely = and error out if it receives them.

The issue with negative = is less about the integer encoding. It=E2=80=99s about the lack of a = proper standard for time before 1970. Also, you might save some object = code by not implementing negative dates as the need for them will be = rare.

LL





On Jul 5, 2018, at 5:10 PM, Macieira, Thiago <thiago.macieira@intel.com> wrote:

Hello Laurence

I don't see why you need to talk about the unsigned width. It's encoded = as a CBOR unsigned number (major type 0) and therefore uses as many bits = as necessary. That is, it has needed 32 bits to encode since the second = day of the epoch and will continue to need only that much until 2106. If someone wishes to represent dates beyond = that, they'll need 64-bit width. But if someone wishes to encode only = the epoch itself, they need only 1 byte.

Similarly for negative: any date prior to 1970 will require negative = numbers.

So if you want to implement the minimum, you implement CBOR unsigned and = negative, of all widths. Any implementation not supporting 64-bit width = integers is not compliant. They may be able to get away with it, but if = they fail to parse wider data, the bug is in them, not the sender.

PS: double has 53 bits of resolution, not 52.
From: CBOR [cbor-bounces@ietf.org] on behalf of Laurence Lundblade = [lgl@island-resort.com]
Sent: Thursday, July 05, 2018 14:23
To: Carsten Bormann
Cc: cbor@ietf.org
Subject: Re: [Cbor] PR for improving epoch time (tag = 1)

Hi Carsten,

I=E2=80=99m definitely after tightening up tag 1 here = (and exploring as an example around canonicalization, variation and = options in CBOR).  I=E2=80=99m not a time geek, nor do I have any = use cases other than tag 1. I think tag 1 time probably covers the vast majority of use cases for time in CBOR protocols.

I=E2=80=99ve updated the PR so floating point is no longer removed, = but still discourage its use unless greater than 1 second precision is = needed. The interop problems I see with floating point are:
 - Small CPUs like ARM Cortex M0 and ATmega16/32U4 = do not support it
 - Floating-point is extra work for a CBOR = implementor (It was for me anyway)

There should be as few choices for the implementor as = possible and those there are should be clear. So the choices in = the PR are mostly a) 64 or 32-bit integer = support, b) support negative time (to sort your Jimi Hendrix albums), c) support = double if you need microsecond time.

I do think there should be clear requirements for each = tag, maybe even canonicalization requirements per tag, especially for a = tag that will be widely implemented and used like tag 1 and especially = for something as problematic as time.

You=E2=80=99ll probably say I have way too much time on = my hands, but there=E2=80=99s a tag 1 implementor FAQ below.

LL



Tag 1 = Implementator=E2=80=99s FAQ

<PastedGra= phic-2.png>


Q: I just want to implement the minimum, = what should I do?
A: You should support 64-bit unsigned = encoding. This will cover just about every use case because it works = from 1970 until over 500 billion years in the future and 1 second = resolution is enough for most human activity. Note that time values up to 2106 will be encoded as 32-bit integers even though 64-bit = integers are supported because only 32-bits are needed to count seconds = up to the year 2106.

Q: I=E2=80=99m implementing on an 8-bit CPU = and 64-bit integers are really a problem.
A: You can support just 32-bit integers in = that case, but they will stop working in 2106.

Q: Why 2106 and not 2038? 
A: Because CBOR encodes positive and = negative integers with different major types and thus is able to use the = full 32-bits for positive integers.

Q: What if I need time values before = 1970? 
A: Implement 64 or 32-bit negative time = values, but note that there is no clear standard for this as POSIX and = UTC time are not defined for this time period. If your implementation = assumes every days is 86,400 seconds and follow the rules for leap years, you should have accuracy to within hours, if not = minutes.

Q: Is Tag 1 better than Tag 0 for time = values?
A: In a lot of ways it is, because it is = just a simple integer. It takes up a lot less space. It is a lot simpler = to parse. Most OS=E2=80=99s have the ability to turn POSIX time into a = structure of month, day, year, hour, minute and second. Note however that POSIX time has a discontinuity of about once every = year for leap second adjustment.

Q: What is a leap second?
A: It actually takes the earth about 1 year = and 1 second to revolve around the sun, so 1 extra second has to be = added almost every year. UTC Time handles this by counting the seconds = from 0-60 (not 0-59) in the last minute of the year. This standard uses POSIX time which can be said to handle this by the = clock stopping for 1 second in the last minute of the = year. 

Q: Do I have to implement floating point = time?
A: No. There are not many use cases that = need it. However for maximal interoperability, it is good to support = it.

Q: When should I use floating = point?
A: Only if you need time resolution greater = than one second. There is no benefit otherwise. 64-bit time can = represent time +/-500 billion years in the same number of bits, so = floating point time is unnecessary for very large times = scales.

Q: What resolution to I get with floating = point?
A: It varies over the years. For 1970 to = 1971 you get almost nanosecond accuracy. For the current century, = 2000-2099, you get microsecond accuracy.  285 million years from = now, it will be less than a second and the 64-bit unsigned = representation will have more resolution. This is because a double only has 52 bits of = resolution.

Q: Should I implement single or double = floating point?
A: If you are going to use floating point = you should always implement double. Single has no advantage over 32-bit = integers. It provides less range and less precision. It has only 23 bits = of resolution. It is of course good to support decoding of single in case some one sends you one, but there no point = to ever sending a tag 1 encoded time value as a single.

Q: Can I disallow floating point time in the = definition of my protocol?
A: Yes. This is a good idea if you do not = need resolution less than one second. It will make implementations = simpler and more compact. Note that while most CPUs do support IEEE 754 = floating point, particularly small ones do not.

Q: What I=E2=80=99m transmitting thousands = of time stamps and space is a problem?
A: If you want to maintain 1 second = resolution, there is really no more compact way to transmit time than = tag 1 32-bit or 64-bit integer. If you wish reduce resolution, use a = different time, perhaps one that counts days rather than = seconds. 
 






On Jul 2, 2018, at 12:10 PM, Carsten Bormann <cabo@tzi.org> wrote:

Hi Laurence,

the representation of time is indeed one of those eternal issues in = representation formats.

Tag 1 is relatively well-defined as it is, and I don=E2=80=99t think we = want to change that.
Instead, new tags have been defined for time (and there, of course, also = has been tag 0).

Not all tags need to be defined in the CBOR base document.
In particular, in this round we are aiming to collect the stable parts = of CBOR, as opposed to putting in more bells and whistles.
We are *not* defining a new version of CBOR (there are no versions in = CBOR).

New bells and whistles can be added by just registering tags.
The set of registered tags can at any time be examined at:

https://www.iana.org/assignments/cbor-tags/cbor-tags.xht= ml

Looking for =E2=80=9Ctime=E2=80=9D, we see (apart from 0 and 1):

1001 = map extended time [draft-bormann-cbor-time-tag-01]

This tag has been registered a while ago and already has been = implemented in some environments that care about precise time (e.g., = Haskell with its picosecond-based time).

On to the specific changes that you propose:

=E2=80=94 getting rid of floating point time =E2=80=94 I would expect = that is in active use, but I haven=E2=80=99t done a survey. It = definitely is allowed by RFC 8392 (which uses Tag 1 in an indirect way). =  Floating point time has the weird property that its resolution = gets lower the further away you get from the epoch.  But otherwise, it is = fine.  Currently, of the 53 bits of resolution of a binary64, 31 = bits are taken for the integer part, so 22 bits remain for the = fractional part.  That will change to 32+21 in 2038 =E2=80=94 a = date that most people who work with Posix times are aware of, as the integer = time_t no longer will fit in a signed 32-bit int then.  So I = don=E2=80=99t see any deadly interoperability problems that would stop = us from continuing to support floating point valuess in tag 1.  Any specific application can be more selective, if desired.

=E2=80=94 being more explicit about negative values (int or float). =  Good point.

- requiring support for =E2=80=9Cpositive=E2=80=9D (I think you mean = unsigned) integer values.  Just as an application can rule out = floats in its usage of Tag 1, it could do so for integers.  A = generic CBOR implementation that doesn=E2=80=99t support integer values = here could be considered not so bright, though.  (CBOR is more about interoperability than = about conformance, anyway.)

=E2=80=94 comments about serialization (encoding).  I don=E2=80=99t = think a Tag should define that level of requirement.  If an = application wants to use minimal-size encoding, so be it, but that=E2=80=99= s none of the business of a Tag.

So, in summary, I=E2=80=99d say let=E2=80=99s pick a good way to handle = negative numbers (being aware that there is no really good way). =  Probably MJD-based interpretations.  But let=E2=80=99s talk = to astronomers here=E2=80=A6

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


On Jul 2, 2018, at 20:29, Laurence = Lundblade <lgl@island-resort.com> wrote:

I think that the more we can reduce implementation / encoding options = and variability in CBOR the better. Seems this is also what a lot of the = drive for canonicalization is about.

Here is a PR for new text for epoch time (tag 1).  

I don=E2=80=99t know what the philosophy is for compatibility with RFC = 7049. This proposal breaks it. Maybe it should be a different tag value = or such because of that.

The big break is disallowing floating point values because you can do = better in a number of ways by defining a new tag for time expressed in = micro or nano seconds from the epoch in a 64-bit integer (perhaps as = suggested here).

The general decoder implementor and protocol designer is left with only = two choices:
  - Support 64-bit time values or not
  - Support negative time values or not

The protocol designer should of course make a call on these choices so = there aren=E2=80=99t interop problems.

There=E2=80=99s more detailed rationale in the PR comments.
=
I=E2=80=99m curious what you think. :-)

LL


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

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


= --Apple-Mail=_B5DEB86B-7004-46E7-B569-4DAE9093B6F0-- From nobody Fri Jul 6 10:53:40 2018 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 A38CF129C6A for ; Fri, 6 Jul 2018 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bwesouwSB4PI for ; Fri, 6 Jul 2018 10:53:35 -0700 (PDT) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 B0D20130E18 for ; Fri, 6 Jul 2018 10:53:35 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 10:53:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,317,1526367600"; d="scan'208";a="64962109" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga003.jf.intel.com with ESMTP; 06 Jul 2018 10:53:27 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.58) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 6 Jul 2018 10:53:27 -0700 From: Thiago Macieira To: "cbor@ietf.org" Date: Fri, 6 Jul 2018 10:53:26 -0700 Message-ID: <4245031.mVqTGvMvuG@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <2BA55353-6A8A-451D-AB7B-6868F3C1DEB3@island-resort.com> References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47@irsmsx105.ger.corp.intel.com> <2BA55353-6A8A-451D-AB7B-6868F3C1DEB3@island-resort.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.7.197.58] Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 17:53:38 -0000 On Friday, 6 July 2018 09:20:06 PDT Laurence Lundblade wrote: > Hi Thiago, >=20 > Correct me if I=E2=80=99m wrong, but it is OK to pick and choose bits of = CBOR to > implement. So, for a chip like the AtMega32U4 > , RAM is so tight > (2.5KB) that you might not use or want 64-bit unsigned for anything. It= =E2=80=99s > also an 8-bit CPU so just moving 64-bit quantities around, byte-swapping > them and such is going to use a lot of instructions. It's ok to pick and choose core features, but only if you don't care about= =20 interoperability. A non-canonical sender could send an 8-bit value in a 64- bit-wide field for some reason, like simplification of the encoding procedu= re.=20 The receiver must be able to handle that. Ditto for half-precision floating= =20 point: the canonical representation of infinity and NaN are in half-precisi= on,=20 so implementations really should implement those to make sure they can pars= e=20 data coming from others. Tags are a different story, since one really expects that a tag be sent onl= y=20 when the receiver is expected to know it. Replacing a core data type with a= =20 tagged type (bigint, bigfloat, etc.) is very different from replacing an 8-= bit=20 number with a 64-bit one. This is especially true after a protocol schema is defined (e.g., via CDDL)= =2E=20 The schema only says "int" or "uint" or "int / float", but never the width = for=20 either. > As I understand the CBOR philosophy, it is a design goal to allow designs= of > protocols that explicitly don=E2=80=99t use parts of CBOR and to even err= or out on > valid CBOR because it is outside of what is allowed for the protocol. So a > protocol designed for super tiny devices like the AtMega could disallow > unsigned 64 entirely and error out if it receives them. If the number is out of range for the data in question, this is probably ok= =2E=20 But the protocol then needs to emphasise the need for canonical encoding, s= o a=20 number less than 255 is never encoded with more than 1+1 bytes. Note how=20 canonical encoding then turns around and requires half-precision floating=20 point. In specific for times, I don't think you need to mention anything. If I wan= t=20 to send a date in the 2200s, there's nothing wrong with my code. The receiv= er=20 could decide to reject that because the date is meaningless, but that's an= =20 implementation detail based on the data, not the format. > The issue with negative is less about the integer encoding. It=E2=80=99s = about the > lack of a proper standard for time before 1970. Also, you might save some > object code by not implementing negative dates as the need for them will = be > rare. Lots of people alive today were born before 1970. I'd think they would want= =20 their birth dates to be representable. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Fri Jul 6 21:13:51 2018 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 B3748130E1D for ; Fri, 6 Jul 2018 21:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF_pS6HLHnTg for ; Fri, 6 Jul 2018 21:13:47 -0700 (PDT) Received: from p3plsmtpa08-08.prod.phx3.secureserver.net (p3plsmtpa08-08.prod.phx3.secureserver.net [173.201.193.109]) (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 27AED1292F1 for ; Fri, 6 Jul 2018 21:13:47 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id bebSfBAflTeHsbebSfAVBZ; Fri, 06 Jul 2018 21:13:46 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Laurence Lundblade In-Reply-To: <4245031.mVqTGvMvuG@tjmaciei-mobl1> Date: Fri, 6 Jul 2018 21:13:46 -0700 Cc: "cbor@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <6A1C3E1AA12C8F40BA6CB7A58268DABD013CD6DF47@irsmsx105.ger.corp.intel.com> <2BA55353-6A8A-451D-AB7B-6868F3C1DEB3@island-resort.com> <4245031.mVqTGvMvuG@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfHH2/JxZZa/BQ4N6nWc9SIdR/GeIS/FdsuAJy1YnG3W2OCLTUwzdulmEMuYuAVjkD7bYzRpmqqtQ3s91d5TIF9X1M1wPyBFPEDH/LLwMQGch5KF9SzJL k3CVaTCMjEAIVXTGwG/1RrWC/UVP68YGAcUnFulqJAy3VU/n8+RIGbQBy5Sp2+t90VoTGQyeZGfnKq/YwSdMw6QERiwM53qel3w= Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 04:13:50 -0000 Hmm, seems like interoperability should be for every protocol that uses = CBOR no matter what types they use and whether or not canonicalization = is used. Take a really dumb cheap sensor that sends a lot of data to a smart = capable server, perhaps a camera of some sort. The CBOR protocol uses = indefinite lengths for both bstr and unsorted maps because the data is = too large to buffer in the small sensor=E2=80=99s memory. The sensor = may be dumb, but it is trusted to never duplicate map entries. The = sensor only receives integer acks and command from the server so it = doesn=E2=80=99t have to parse much at all.=20 I=E2=80=99m thinking canonicalization should not be the only path to = excellent interoperability. LL > On Jul 6, 2018, at 10:53 AM, Thiago Macieira = wrote: >=20 > On Friday, 6 July 2018 09:20:06 PDT Laurence Lundblade wrote: >> Hi Thiago, >>=20 >> Correct me if I=E2=80=99m wrong, but it is OK to pick and choose bits = of CBOR to >> implement. So, for a chip like the AtMega32U4 >> , RAM is so = tight >> (2.5KB) that you might not use or want 64-bit unsigned for anything. = It=E2=80=99s >> also an 8-bit CPU so just moving 64-bit quantities around, = byte-swapping >> them and such is going to use a lot of instructions. >=20 > It's ok to pick and choose core features, but only if you don't care = about=20 > interoperability. A non-canonical sender could send an 8-bit value in = a 64- > bit-wide field for some reason, like simplification of the encoding = procedure.=20 > The receiver must be able to handle that. Ditto for half-precision = floating=20 > point: the canonical representation of infinity and NaN are in = half-precision,=20 > so implementations really should implement those to make sure they can = parse=20 > data coming from others. >=20 > Tags are a different story, since one really expects that a tag be = sent only=20 > when the receiver is expected to know it. Replacing a core data type = with a=20 > tagged type (bigint, bigfloat, etc.) is very different from replacing = an 8-bit=20 > number with a 64-bit one. >=20 > This is especially true after a protocol schema is defined (e.g., via = CDDL).=20 > The schema only says "int" or "uint" or "int / float", but never the = width for=20 > either. >=20 >> As I understand the CBOR philosophy, it is a design goal to allow = designs of >> protocols that explicitly don=E2=80=99t use parts of CBOR and to even = error out on >> valid CBOR because it is outside of what is allowed for the protocol. = So a >> protocol designed for super tiny devices like the AtMega could = disallow >> unsigned 64 entirely and error out if it receives them. >=20 > If the number is out of range for the data in question, this is = probably ok.=20 > But the protocol then needs to emphasise the need for canonical = encoding, so a=20 > number less than 255 is never encoded with more than 1+1 bytes. Note = how=20 > canonical encoding then turns around and requires half-precision = floating=20 > point. >=20 > In specific for times, I don't think you need to mention anything. If = I want=20 > to send a date in the 2200s, there's nothing wrong with my code. The = receiver=20 > could decide to reject that because the date is meaningless, but = that's an=20 > implementation detail based on the data, not the format. >=20 >> The issue with negative is less about the integer encoding. It=E2=80=99= s about the >> lack of a proper standard for time before 1970. Also, you might save = some >> object code by not implementing negative dates as the need for them = will be >> rare. >=20 > Lots of people alive today were born before 1970. I'd think they would = want=20 > their birth dates to be representable. >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sun Jul 8 22:05:58 2018 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 C38CC130F15 for ; Sun, 8 Jul 2018 22:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 KSglu1SVTTIw for ; Sun, 8 Jul 2018 22:05:54 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 D8A85130DFA for ; Sun, 8 Jul 2018 22:05:54 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2018 22:05:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,328,1526367600"; d="scan'208";a="55377774" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga008.jf.intel.com with ESMTP; 08 Jul 2018 22:05:52 -0700 Received: from tjmaciei-mobl1.localnet (10.254.39.42) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 8 Jul 2018 22:05:52 -0700 From: Thiago Macieira To: Laurence Lundblade CC: "cbor@ietf.org" Date: Sun, 8 Jul 2018 22:05:51 -0700 Message-ID: <2526611.AW0aMvYA91@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <4245031.mVqTGvMvuG@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.254.39.42] Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 05:05:57 -0000 Which is why supporting all core types should be a requirement. If the=20 protocol calls for an integer at a given position, then any encoding from 1= to=20 9 bytes should be accepted. Floating point isn't required if the protocol=20 requires an integer there. The alternative is that different implementations support different aspects= of=20 the encoding. On Friday, 6 July 2018 21:13:46 PDT Laurence Lundblade wrote: > Hmm, seems like interoperability should be for every protocol that uses C= BOR > no matter what types they use and whether or not canonicalization is used. >=20 > Take a really dumb cheap sensor that sends a lot of data to a smart capab= le > server, perhaps a camera of some sort. The CBOR protocol uses indefinite > lengths for both bstr and unsorted maps because the data is too large to > buffer in the small sensor=E2=80=99s memory. The sensor may be dumb, but= it is > trusted to never duplicate map entries. The sensor only receives integer > acks and command from the server so it doesn=E2=80=99t have to parse much= at all. >=20 > I=E2=80=99m thinking canonicalization should not be the only path to exce= llent > interoperability. >=20 > LL >=20 > > On Jul 6, 2018, at 10:53 AM, Thiago Macieira > > wrote:>=20 > > On Friday, 6 July 2018 09:20:06 PDT Laurence Lundblade wrote: > >> Hi Thiago, > >>=20 > >> Correct me if I=E2=80=99m wrong, but it is OK to pick and choose bits = of CBOR to > >> implement. So, for a chip like the AtMega32U4 > >> , RAM is so tight > >> (2.5KB) that you might not use or want 64-bit unsigned for anything. I= t=E2=80=99s > >> also an 8-bit CPU so just moving 64-bit quantities around, byte-swappi= ng > >> them and such is going to use a lot of instructions. > >=20 > > It's ok to pick and choose core features, but only if you don't care ab= out > > interoperability. A non-canonical sender could send an 8-bit value in a > > 64- > > bit-wide field for some reason, like simplification of the encoding > > procedure. The receiver must be able to handle that. Ditto for > > half-precision floating point: the canonical representation of infinity > > and NaN are in half-precision, so implementations really should impleme= nt > > those to make sure they can parse data coming from others. > >=20 > > Tags are a different story, since one really expects that a tag be sent > > only when the receiver is expected to know it. Replacing a core data ty= pe > > with a tagged type (bigint, bigfloat, etc.) is very different from > > replacing an 8-bit number with a 64-bit one. > >=20 > > This is especially true after a protocol schema is defined (e.g., via > > CDDL). The schema only says "int" or "uint" or "int / float", but never > > the width for either. > >=20 > >> As I understand the CBOR philosophy, it is a design goal to allow desi= gns > >> of protocols that explicitly don=E2=80=99t use parts of CBOR and to ev= en error > >> out on valid CBOR because it is outside of what is allowed for the > >> protocol. So a protocol designed for super tiny devices like the AtMega > >> could disallow unsigned 64 entirely and error out if it receives them. > >=20 > > If the number is out of range for the data in question, this is probably > > ok. But the protocol then needs to emphasise the need for canonical > > encoding, so a number less than 255 is never encoded with more than 1+1 > > bytes. Note how canonical encoding then turns around and requires > > half-precision floating point. > >=20 > > In specific for times, I don't think you need to mention anything. If I > > want to send a date in the 2200s, there's nothing wrong with my code. T= he > > receiver could decide to reject that because the date is meaningless, b= ut > > that's an implementation detail based on the data, not the format. > >=20 > >> The issue with negative is less about the integer encoding. It=E2=80= =99s about > >> the > >> lack of a proper standard for time before 1970. Also, you might save s= ome > >> object code by not implementing negative dates as the need for them wi= ll > >> be > >> rare. > >=20 > > Lots of people alive today were born before 1970. I'd think they would > > want > > their birth dates to be representable. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 9 12:12:49 2018 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 72F48130E73 for ; Mon, 9 Jul 2018 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61HahO8MShA2 for ; Mon, 9 Jul 2018 12:12:44 -0700 (PDT) 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 6131912426A for ; Mon, 9 Jul 2018 12:12:44 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id cbaVftpWBdKQecbaVf6RfU; Mon, 09 Jul 2018 12:12:43 -0700 From: Laurence Lundblade Message-Id: <4BF40624-C87B-4FFD-BFF5-2296393154FC@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_248D5BB8-1756-452A-8925-17EF8F759A51" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 9 Jul 2018 12:12:43 -0700 In-Reply-To: <2526611.AW0aMvYA91@tjmaciei-mobl1> Cc: "cbor@ietf.org" To: Thiago Macieira References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <4245031.mVqTGvMvuG@tjmaciei-mobl1> <2526611.AW0aMvYA91@tjmaciei-mobl1> X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfIIralhszcuedVfmnAxgJmOIB+1oeBjlq1moxFlzDUrc3+yhKiqwFVNhYpFzmlmYPAPwKIJ9IXI109Gb8ms3U0U4T/DTVZy1zPCdJJCBBfLOKvZQYcay TvNSgt5p9c9mGjsL4843DziWbGnmfVTwgzImz8tfT7A8T3JffrBMldiC1mz2c+Qy7YaCn+Ah4VHxg/KyBrfk49idTvbQaMU7dJM= Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 19:12:48 -0000 --Apple-Mail=_248D5BB8-1756-452A-8925-17EF8F759A51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Thiago, Not sure I=E2=80=99m following what you are saying.=20 To make the example more specific: It is a dumb sensor that generates a lot of data =E2=80=94 a = camera/imager of some sort, a flow sensor... It uses an 8-bit CPU with only a few KB of on-board RAM like the = AtMega32U4 It talks to a smart, much more capable server The CBOR protocol involves the server sending integer commands to the = device and the device sending back the data and not much more.=20 The commands are indicated by integers from 0-20 so the device never = will need to parse anything but the shortest integers. Writing code to = parse 64-bit integers on the 8-bit CPU would be a huge waste of code.=20 The device sends data back as maps of bstrs. There is no RAM for = buffering the full maps and bstrs, so indefinite lengths are used. Maps = are not sorted.=20 The device implements only three CBOR things: Decoding major type 0 only for values up to 24 (no other parsing!) Encoding indefinite length maps Encoding indefinite length bstrs To require this use case to use canonicalization to achieve = interoperability, would require a big jump in RAM and thus probably a = more expensive CPU with more on-board RAM or adding a RAM part to the = device.=20 It seems like the frame-up here is more like this: 1) You define your CBOR protocol in writing, perhaps with CDDL. That = defines what types and encoding are going to be used. This is pretty = much what we do with all the ASN.1 protocol definitions in lots of = different RFCs. 2) When you implement, use a CBOR library that does what is needed. It = needs to support all the types needed, be small enough, be in the right = language=E2=80=A6 You have some thoughts on which formalism will make this example = interop? LL > On Jul 8, 2018, at 10:05 PM, Thiago Macieira = wrote: >=20 > Which is why supporting all core types should be a requirement. If the=20= > protocol calls for an integer at a given position, then any encoding = from 1 to=20 > 9 bytes should be accepted. Floating point isn't required if the = protocol=20 > requires an integer there. >=20 > The alternative is that different implementations support different = aspects of=20 > the encoding. >=20 > On Friday, 6 July 2018 21:13:46 PDT Laurence Lundblade wrote: >> Hmm, seems like interoperability should be for every protocol that = uses CBOR >> no matter what types they use and whether or not canonicalization is = used. >>=20 >> Take a really dumb cheap sensor that sends a lot of data to a smart = capable >> server, perhaps a camera of some sort. The CBOR protocol uses = indefinite >> lengths for both bstr and unsorted maps because the data is too large = to >> buffer in the small sensor=E2=80=99s memory. The sensor may be dumb, = but it is >> trusted to never duplicate map entries. The sensor only receives = integer >> acks and command from the server so it doesn=E2=80=99t have to parse = much at all. >>=20 >> I=E2=80=99m thinking canonicalization should not be the only path to = excellent >> interoperability. >>=20 >> LL >>=20 >>> On Jul 6, 2018, at 10:53 AM, Thiago Macieira = >>> wrote:>=20 >>> On Friday, 6 July 2018 09:20:06 PDT Laurence Lundblade wrote: >>>> Hi Thiago, >>>>=20 >>>> Correct me if I=E2=80=99m wrong, but it is OK to pick and choose = bits of CBOR to >>>> implement. So, for a chip like the AtMega32U4 >>>> , RAM is so = tight >>>> (2.5KB) that you might not use or want 64-bit unsigned for = anything. It=E2=80=99s >>>> also an 8-bit CPU so just moving 64-bit quantities around, = byte-swapping >>>> them and such is going to use a lot of instructions. >>>=20 >>> It's ok to pick and choose core features, but only if you don't care = about >>> interoperability. A non-canonical sender could send an 8-bit value = in a >>> 64- >>> bit-wide field for some reason, like simplification of the encoding >>> procedure. The receiver must be able to handle that. Ditto for >>> half-precision floating point: the canonical representation of = infinity >>> and NaN are in half-precision, so implementations really should = implement >>> those to make sure they can parse data coming from others. >>>=20 >>> Tags are a different story, since one really expects that a tag be = sent >>> only when the receiver is expected to know it. Replacing a core data = type >>> with a tagged type (bigint, bigfloat, etc.) is very different from >>> replacing an 8-bit number with a 64-bit one. >>>=20 >>> This is especially true after a protocol schema is defined (e.g., = via >>> CDDL). The schema only says "int" or "uint" or "int / float", but = never >>> the width for either. >>>=20 >>>> As I understand the CBOR philosophy, it is a design goal to allow = designs >>>> of protocols that explicitly don=E2=80=99t use parts of CBOR and to = even error >>>> out on valid CBOR because it is outside of what is allowed for the >>>> protocol. So a protocol designed for super tiny devices like the = AtMega >>>> could disallow unsigned 64 entirely and error out if it receives = them. >>>=20 >>> If the number is out of range for the data in question, this is = probably >>> ok. But the protocol then needs to emphasise the need for canonical >>> encoding, so a number less than 255 is never encoded with more than = 1+1 >>> bytes. Note how canonical encoding then turns around and requires >>> half-precision floating point. >>>=20 >>> In specific for times, I don't think you need to mention anything. = If I >>> want to send a date in the 2200s, there's nothing wrong with my = code. The >>> receiver could decide to reject that because the date is = meaningless, but >>> that's an implementation detail based on the data, not the format. >>>=20 >>>> The issue with negative is less about the integer encoding. It=E2=80=99= s about >>>> the >>>> lack of a proper standard for time before 1970. Also, you might = save some >>>> object code by not implementing negative dates as the need for them = will >>>> be >>>> rare. >>>=20 >>> Lots of people alive today were born before 1970. I'd think they = would >>> want >>> their birth dates to be representable. >=20 >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_248D5BB8-1756-452A-8925-17EF8F759A51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Thiago,

Not sure = I=E2=80=99m following what you are saying. 

To make the example more = specific:
  • It is a = dumb sensor that generates a lot of data =E2=80=94 a camera/imager of = some sort, a flow sensor...
  • It uses an 8-bit CPU with = only a few KB of on-board RAM like the = AtMega32U4
  • It talks to a smart, much more capable = server
The CBOR protocol involves the = server sending integer commands to the device and the device sending = back the data and not much more. 

The commands are indicated by integers = from 0-20 so the device never will need to parse anything but the = shortest integers. Writing code to parse 64-bit integers on the 8-bit = CPU would be a huge waste of code. 

The device sends data back as maps of = bstrs. There is no RAM for buffering the full maps and bstrs, so = indefinite lengths are used. Maps are not sorted. 

The device implements = only three CBOR things:
    Decoding major type 0 only for values up to 24 (no other = parsing!)
  • Encoding indefinite length maps
  • Encoding indefinite length bstrs

To require this use case = to use canonicalization to achieve interoperability, would require a big = jump in RAM and thus probably a more expensive CPU with more on-board = RAM or adding a RAM part to the device. 


It = seems like the frame-up here is more like this:

1) You define your CBOR = protocol in writing, perhaps with CDDL. That defines what types and = encoding are going to be used. This is pretty much what we do with all = the ASN.1 protocol definitions in lots of different RFCs.

2) When you implement, = use a CBOR library that does what is needed. It needs to support all the = types needed, be small enough, be in the right = language=E2=80=A6


You = have some thoughts on which formalism will make this example = interop?

LL



On Jul = 8, 2018, at 10:05 PM, Thiago Macieira <thiago.macieira@intel.com> wrote:

Which = is why supporting all core types should be a requirement. If the
protocol calls for an integer at a given position, then any = encoding from 1 to
9 bytes should be accepted. Floating = point isn't required if the protocol
requires an integer = there.

The alternative is that different = implementations support different aspects of
the = encoding.

On Friday, 6 July 2018 21:13:46 = PDT Laurence Lundblade wrote:
Hmm, seems like interoperability should be for every protocol = that uses CBOR
no matter what types they use and whether = or not canonicalization is used.

Take a = really dumb cheap sensor that sends a lot of data to a smart capable
server, perhaps a camera of some sort. The CBOR protocol uses = indefinite
lengths for both bstr and unsorted maps because = the data is too large to
buffer in the small sensor=E2=80=99= s memory.  The sensor may be dumb, but it is
trusted = to never duplicate map entries. The sensor only receives integer
acks and command from the server so it doesn=E2=80=99t have = to parse much at all.

I=E2=80=99m thinking = canonicalization should not be the only path to excellent
interoperability.

LL

On Jul 6, = 2018, at 10:53 AM, Thiago Macieira <thiago.macieira@intel.com>
wrote:> =
On Friday, 6 July 2018 09:20:06 PDT Laurence Lundblade = wrote:
Hi Thiago,

Correct me if I=E2=80=99m wrong, but it is OK = to pick and choose bits of CBOR to
implement. So, for a = chip like the AtMega32U4
<https://www.microchip.com/wwwproducts/en/ATmega32U4>, = RAM is so tight
(2.5KB) that you might not use or want = 64-bit unsigned for anything. It=E2=80=99s
also an 8-bit = CPU so just moving 64-bit quantities around, byte-swapping
them and such is going to use a lot of instructions.

It's ok to pick and choose core = features, but only if you don't care about
interoperability.= A non-canonical sender could send an 8-bit value in a
64-
bit-wide field for some reason, like = simplification of the encoding
procedure. The receiver = must be able to handle that. Ditto for
half-precision = floating point: the canonical representation of infinity
and= NaN are in half-precision, so implementations really should = implement
those to make sure they can parse data coming = from others.

Tags are a different story, = since one really expects that a tag be sent
only when the = receiver is expected to know it. Replacing a core data type
with a tagged type (bigint, bigfloat, etc.) is very different = from
replacing an 8-bit number with a 64-bit one.

This is especially true after a protocol = schema is defined (e.g., via
CDDL). The schema only says = "int" or "uint" or "int / float", but never
the width for = either.

As I understand the CBOR philosophy, it is a design goal to = allow designs
of protocols that explicitly don=E2=80=99t = use parts of CBOR and to even error
out on valid CBOR = because it is outside of what is allowed for the
protocol. = So a protocol designed for super tiny devices like the AtMega
could disallow unsigned 64 entirely and error out if it = receives them.

If the number = is out of range for the data in question, this is probably
ok. But the protocol then needs to emphasise the need for = canonical
encoding, so a number less than 255 is never = encoded with more than 1+1
bytes. Note how canonical = encoding then turns around and requires
half-precision = floating point.

In specific for times, I = don't think you need to mention anything. If I
want to = send a date in the 2200s, there's nothing wrong with my code. The
receiver could decide to reject that because the date is = meaningless, but
that's an implementation detail based on = the data, not the format.

The issue with negative is less about the = integer encoding. It=E2=80=99s about
the
lack = of a proper standard for time before 1970. Also, you might save some
object code by not implementing negative dates as the need = for them will
be
rare.

Lots of people alive today were = born before 1970. I'd think they would
want
their birth dates to be representable.


-- =
Thiago Macieira - thiago.macieira (AT) intel.com
=  Software Architect - Intel Open Source Technology Center



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

= --Apple-Mail=_248D5BB8-1756-452A-8925-17EF8F759A51-- From nobody Mon Jul 9 13:59:23 2018 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 48380131059 for ; Mon, 9 Jul 2018 13:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 82PXP7fDZi6O for ; Mon, 9 Jul 2018 13:59:19 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 33433131057 for ; Mon, 9 Jul 2018 13:59:19 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 13:59:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,330,1526367600"; d="scan'208";a="73450073" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 09 Jul 2018 13:59:11 -0700 Received: from tjmaciei-mobl1.localnet (10.144.145.79) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Jul 2018 13:59:10 -0700 From: Thiago Macieira To: Laurence Lundblade CC: "cbor@ietf.org" Date: Mon, 9 Jul 2018 13:59:09 -0700 Message-ID: <2099126.WyIPBu9YBr@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <4BF40624-C87B-4FFD-BFF5-2296393154FC@island-resort.com> References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <2526611.AW0aMvYA91@tjmaciei-mobl1> <4BF40624-C87B-4FFD-BFF5-2296393154FC@island-resort.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.144.145.79] Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 20:59:22 -0000 On Monday, 9 July 2018 12:12:43 PDT Laurence Lundblade wrote: > The commands are indicated by integers from 0-20 so the device never will > need to parse anything but the shortest integers. Writing code to parse > 64-bit integers on the 8-bit CPU would be a huge waste of code. Now imagine that the controller device is a dumb 16-bit MCU that as a dumb= =20 encoder that always sends 16-bit values because it can simply encode as 0x19 V1 V2=20 for any integral value. > The device implements only three CBOR things: > Decoding major type 0 only for values up to 24 (no other parsing!) > Encoding indefinite length maps > Encoding indefinite length bstrs >=20 > To require this use case to use canonicalization to achieve > interoperability, would require a big jump in RAM and thus probably a more > expensive CPU with more on-board RAM or adding a RAM part to the device. Agreed. This protocol should not require canonicalisation. > It seems like the frame-up here is more like this: >=20 > 1) You define your CBOR protocol in writing, perhaps with CDDL. That defi= nes > what types and encoding are going to be used. This is pretty much what we > do with all the ASN.1 protocol definitions in lots of different RFCs. >=20 > 2) When you implement, use a CBOR library that does what is needed. It ne= eds > to support all the types needed, be small enough, be in the right languag= e=E2=80=A6 >=20 >=20 > You have some thoughts on which formalism will make this example interop? Yes. Your 8-bit sensor needs to support 16-bit numbers to interoperate with= =20 that controller. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 9 15:40:59 2018 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 EBCA0127333 for ; Mon, 9 Jul 2018 15:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWl0klVde624 for ; Mon, 9 Jul 2018 15:40:52 -0700 (PDT) Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 E1B70130E67 for ; Mon, 9 Jul 2018 15:40:51 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id cepvfvr7ymHzrcepvfKIJq; Mon, 09 Jul 2018 15:40:51 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Laurence Lundblade In-Reply-To: <2099126.WyIPBu9YBr@tjmaciei-mobl1> Date: Mon, 9 Jul 2018 15:39:47 -0700 Cc: "cbor@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <2526611.AW0aMvYA91@tjmaciei-mobl1> <4BF40624-C87B-4FFD-BFF5-2296393154FC@island-resort.com> <2099126.WyIPBu9YBr@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfCLg0KZU/KMUWlJWk1cQzcP1ThmWT/w1DiLF4BLDcNF2y0fPqrw4u7sDumouzj4x55uJDw8kI8F0uHMVvOLqWmRUi2vwgtZZnaK5d77MHdG0fRXPrD6n 2VyBaPnRPDCiThXUB7hRwcpZiTm+0CwAhIBDt1mxD5dxE1BmNTEc0e6srbdno83NscMMsJieC4xlD9b/nSz4pgseoepP6VCLyF8= Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 22:40:57 -0000 Shouldn=E2=80=99t one be able to formally and fully define a CBOR-based = protocol that only ever uses 8-bit integers? In such a protocol the = 16-bit encoding from the 16-bit MCU would be quite clearly out of spec = (it=E2=80=99s also not that hard for a 16-bit MCU to always encode in = 8-bits especially if it never has to encode 16-bits).=20 LL > On Jul 9, 2018, at 1:59 PM, Thiago Macieira = wrote: >=20 > On Monday, 9 July 2018 12:12:43 PDT Laurence Lundblade wrote: >> The commands are indicated by integers from 0-20 so the device never = will >> need to parse anything but the shortest integers. Writing code to = parse >> 64-bit integers on the 8-bit CPU would be a huge waste of code. >=20 > Now imagine that the controller device is a dumb 16-bit MCU that as a = dumb=20 > encoder that always sends 16-bit values because it can simply encode = as >=20 > 0x19 V1 V2=20 >=20 > for any integral value. >=20 >> The device implements only three CBOR things: >> Decoding major type 0 only for values up to 24 (no other parsing!) >> Encoding indefinite length maps >> Encoding indefinite length bstrs >>=20 >> To require this use case to use canonicalization to achieve >> interoperability, would require a big jump in RAM and thus probably a = more >> expensive CPU with more on-board RAM or adding a RAM part to the = device. >=20 > Agreed. This protocol should not require canonicalisation. >=20 >> It seems like the frame-up here is more like this: >>=20 >> 1) You define your CBOR protocol in writing, perhaps with CDDL. That = defines >> what types and encoding are going to be used. This is pretty much = what we >> do with all the ASN.1 protocol definitions in lots of different RFCs. >>=20 >> 2) When you implement, use a CBOR library that does what is needed. = It needs >> to support all the types needed, be small enough, be in the right = language=E2=80=A6 >>=20 >>=20 >> You have some thoughts on which formalism will make this example = interop? >=20 > Yes. Your 8-bit sensor needs to support 16-bit numbers to interoperate = with=20 > that controller. >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >=20 >=20 >=20 >=20 From nobody Mon Jul 9 16:16:30 2018 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 7C21C127332 for ; Mon, 9 Jul 2018 16:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 dE_Vxsho0KuW for ; Mon, 9 Jul 2018 16:16:20 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 33A8A130DE9 for ; Mon, 9 Jul 2018 16:16:20 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2018 16:16:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,330,1526367600"; d="scan'208";a="56357841" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga006.jf.intel.com with ESMTP; 09 Jul 2018 16:16:19 -0700 Received: from tjmaciei-mobl1.localnet (10.144.145.79) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Jul 2018 16:16:19 -0700 From: Thiago Macieira To: CC: Laurence Lundblade Date: Mon, 9 Jul 2018 16:16:17 -0700 Message-ID: <2498851.RLNLc8PV1A@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <2099126.WyIPBu9YBr@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.144.145.79] Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 23:16:25 -0000 On Monday, 9 July 2018 15:39:47 PDT Laurence Lundblade wrote: > Shouldn=E2=80=99t one be able to formally and fully define a CBOR-based p= rotocol > that only ever uses 8-bit integers?=20 In my opinion? No. CDDL does not support that either. It supports specifying ranges (minimum &= =20 maximum values), but not the width of the payload. But in your protocol, if you want this, you can explicitly say so. It won't= be=20 done with CDDL, but with extra wording in your spec. > In such a protocol the 16-bit encoding > from the 16-bit MCU would be quite clearly out of spec (it=E2=80=99s also= not that > hard for a 16-bit MCU to always encode in 8-bits especially if it never h= as > to encode 16-bits). Suppose it does, which is why it encodes as 16-bit. It may be rare, even. B= ut=20 it saves on one compare-and-branch, plus having a variable sized encoding. = No=20 doubt that this non-canonical encoding saves on code size. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 9 17:04:15 2018 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 4BFEE130EA1 for ; Mon, 9 Jul 2018 17:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h809iw2nMivc for ; Mon, 9 Jul 2018 17:04:10 -0700 (PDT) Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.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 C667C130DC7 for ; Mon, 9 Jul 2018 17:04:10 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id cg8WfSJ1zzJpRcg8WfM2Io; Mon, 09 Jul 2018 17:04:09 -0700 From: Laurence Lundblade Message-Id: <641FA2EA-721F-483A-BF19-FDCFB837D9A8@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F2BD4E0-0E31-43EA-8CD4-3CCAB89358E9" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 9 Jul 2018 17:04:08 -0700 In-Reply-To: <2498851.RLNLc8PV1A@tjmaciei-mobl1> Cc: cbor@ietf.org To: Thiago Macieira References: <4B658A68-36AC-4B31-92EC-5BEECE6DC65F@island-resort.com> <2099126.WyIPBu9YBr@tjmaciei-mobl1> <2498851.RLNLc8PV1A@tjmaciei-mobl1> X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfGxgbp6EUSBclPVVCF3yjPa8+wlA7ZS7DiZy9HWJ4bIFtH4qlf8cTFR6GwNFMD7XW/z72Ejbedz4wVAgfTMC5zLpvOJoERxvtqc/GSVeaG2UO1n8tGS1 cepeREYuRXNmhfhMSuy+TeYD/VF2Z/sNoViZksuTG8Tzt9muxcbcFTGW41mD6L2XHYQybx3I6f4ryMrz6ROcIGiHX/cu8OMijW4= Archived-At: Subject: Re: [Cbor] PR for improving epoch time (tag 1) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 00:04:14 -0000 --Apple-Mail=_7F2BD4E0-0E31-43EA-8CD4-3CCAB89358E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If CDDL let=E2=80=99s you define ranges and canonical encoding is = required, then for the range of 0-20, a 16-bit encoding is clearly out = of spec. The receiver could safely error out on 16-bit integers. Seems = we do have a formal way to define a CBOR-based protocol that only uses = 8-bit integers. The notion of =E2=80=9Cformal specification=E2=80=9D for CBOR-based = protocols seems to be the issue here. Seems like there=E2=80=99s two = ways right now. CDDL (plus canonicalization?) =E2=80=94 Seems to limit some of the CBOR = constructs that can be used. Might not be possible to describe my = example protocol with it. Prose =E2=80=94 This allows any subset of types and encodings to be = used.=20 I suppose it is OK to say that CDDL is the official formal way to define = CBOR-based protocols and really should be used whenever possible. But, = it seems we might have to also say that protocols that work on small = CPUs and in small RAM, might have to define their own protocols in prose = as CDDL can=E2=80=99t do what they want. (Pardon, if I=E2=80=99m missing things about CDDL. I=E2=80=99m not up to = speed on it yet). LL > On Jul 9, 2018, at 4:16 PM, Thiago Macieira = wrote: >=20 > On Monday, 9 July 2018 15:39:47 PDT Laurence Lundblade wrote: >> Shouldn=E2=80=99t one be able to formally and fully define a = CBOR-based protocol >> that only ever uses 8-bit integers?=20 >=20 > In my opinion? No. >=20 > CDDL does not support that either. It supports specifying ranges = (minimum &=20 > maximum values), but not the width of the payload. >=20 > But in your protocol, if you want this, you can explicitly say so. It = won't be=20 > done with CDDL, but with extra wording in your spec. >=20 >> In such a protocol the 16-bit encoding >> from the 16-bit MCU would be quite clearly out of spec (it=E2=80=99s = also not that >> hard for a 16-bit MCU to always encode in 8-bits especially if it = never has >> to encode 16-bits). >=20 > Suppose it does, which is why it encodes as 16-bit. It may be rare, = even. But=20 > it saves on one compare-and-branch, plus having a variable sized = encoding. No=20 > doubt that this non-canonical encoding saves on code size. >=20 > --=20 > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center >=20 >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_7F2BD4E0-0E31-43EA-8CD4-3CCAB89358E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If CDDL let=E2=80=99s you define ranges and canonical = encoding is required, then for the range of 0-20, a 16-bit encoding is = clearly out of spec. The receiver could safely error out on 16-bit = integers. Seems we do have a formal way to define a CBOR-based protocol = that only uses 8-bit integers.

The notion of =E2=80=9Cformal = specification=E2=80=9D for CBOR-based protocols seems to be the issue = here.  Seems like there=E2=80=99s two ways right now.

CDDL (plus = canonicalization?) =E2=80=94 Seems to limit some of the CBOR constructs = that can be used. Might not be possible to describe my example protocol = with it.

Prose = =E2=80=94 This allows any subset of types and encodings to be = used. 

I suppose it is OK to say that CDDL is the official formal = way to define CBOR-based protocols and really should be used whenever = possible. But, it seems we might have to also say that protocols that = work on small CPUs and in small RAM, might have to define their own = protocols in prose as CDDL can=E2=80=99t do what they want.

(Pardon, if I=E2=80=99m = missing things about CDDL. I=E2=80=99m not up to speed on it = yet).

LL



On Jul = 9, 2018, at 4:16 PM, Thiago Macieira <thiago.macieira@intel.com> wrote:

On = Monday, 9 July 2018 15:39:47 PDT Laurence Lundblade wrote:
Shouldn=E2=80=99t one be = able to formally and fully define a CBOR-based protocol
that= only ever uses 8-bit integers?

In my opinion? No.

CDDL does not = support that either. It supports specifying ranges (minimum &
maximum values), but not the width of the payload.

But in your protocol, if you want this, you = can explicitly say so. It won't be
done with CDDL, but = with extra wording in your spec.

In such a protocol the 16-bit encoding
from the 16-bit MCU would be quite clearly out of spec = (it=E2=80=99s also not that
hard for a 16-bit MCU to = always encode in 8-bits especially if it never has
to = encode 16-bits).

Suppose it = does, which is why it encodes as 16-bit. It may be rare, even. But
it saves on one compare-and-branch, plus having a variable = sized encoding. No
doubt that this non-canonical encoding = saves on code size.

--
Thiago = Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel = Open Source Technology Center



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

= --Apple-Mail=_7F2BD4E0-0E31-43EA-8CD4-3CCAB89358E9-- From nobody Thu Jul 12 00:06:45 2018 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 5BA0F13106B for ; Thu, 12 Jul 2018 00:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRgbMuzRDxtY for ; Thu, 12 Jul 2018 00:06:41 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D7C13103A for ; Thu, 12 Jul 2018 00:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6C76adA016046 for ; Thu, 12 Jul 2018 09:06:36 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F1FB.dip0.t-ipconnect.de [93.199.241.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41R6Rw2bl8zDWjB; Thu, 12 Jul 2018 09:06:36 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 553071993.847736-7d60f89451d446f41316cc3f708b3882 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 12 Jul 2018 09:06:35 +0200 Message-Id: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 07:06:44 -0000 To provide extensibility, CDDL provides one major extension point: = control operators. However, the current text does not define how to actually add a control = operator. One approach is that this extension point is there just for evolution of = the language, so any new control operators would be defined by a CDDL = 1.1 or 2.0 document. In this case, there is no need for additional = text. One other approach is to open up that extension point for third-party = specifications. If we do this, we should be providing an IANA registry, = and need to define the registration policy (RFC 8126). Theoretically, = this could be done in a separate document, but the more usual way to do = this is to create the registry in the document to which it applies. If we create such a registry, what should be the registration policy? = How easy should it be to create a control operator (and claim a name for = it)? Section 4 of RFC 8126 proposes a number of potential policies. = Specification Required (which is supported by a designated expert who = decides whether there *is* a specification) seems to be the minimum = requirement we should impose. On the other end of the spectrum, = Standards Action means that that specification must be an approved IETF = standards track (or BCP) RFC, which is not that much different from not = having a registry at all. If we go for RFC Required, the RFC could be = Experimental or Informational, too. Finally, Expert Review is the most = flexible policy, but then we should include text that guides the = designated expert to make a decision. To properly decide which of these approaches is right, we need a crystal = ball. Creating too much latitude can fragment the language and create = uncertainty whether a specification making use of a questionable = extension actually can be used. Creating too much rigidity may be bad = for the evolution of the language and for its ability to address = evolving requirements. I=E2=80=99m currently leaning towards creating a registry and giving it = Expert Review policy, guiding the Designated Expert to accept = registrations where a specification is publicly available (Specification = Required) and has received some community review, the result of which = indicates that there is a good chance that independent implementations = would achieve consistent semantics. That places a pretty big onus on the Designated Expert, whom we=E2=80=99d = need to find once the CDDL RFC is approved. It is also more consensus = oriented than a simple Specification Required but has less process than = an IETF Review or Standards Action (both of which involve the IESG, = which is a scarce resource). It does give the Designated Expert a lot = of leeway to evolve the details of the handling of requests, which may = be a good or a bad thing (in the latter case, the IESG can always = replace the designated expert, but this is a relatively heavyweight = procedure). What do you think? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 12 05:56:44 2018 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 48354130E3A for ; Thu, 12 Jul 2018 05:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qBxGELNRisIr for ; Thu, 12 Jul 2018 05:56:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42D2130DDE for ; Thu, 12 Jul 2018 05:56:39 -0700 (PDT) Received: from Jude (104.129.192.71) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 12 Jul 2018 05:53:07 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> In-Reply-To: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> Date: Thu, 12 Jul 2018 05:56:32 -0700 Message-ID: <005501d419df$c3a726e0$4af574a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIGhlm0TnqyCDKRUz2qWzTTcRmakaQmsosg Content-Language: en-us X-Originating-IP: [104.129.192.71] Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 12:56:43 -0000 I would have a strong preference that this would be done via versioning = of the language. It makes it much easier to say that I have a CDDL = version X item checker rather than trying to say I have a CDDL checker = that support the following set of extensions. Jim > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Thursday, July 12, 2018 12:07 AM > To: cbor@ietf.org > Subject: [Cbor] Should CDDL have an IANA registry for control = operators? > (#17) >=20 > To provide extensibility, CDDL provides one major extension point: = control > operators. >=20 > However, the current text does not define how to actually add a = control > operator. >=20 > One approach is that this extension point is there just for evolution = of the > language, so any new control operators would be defined by a CDDL 1.1 = or > 2.0 document. In this case, there is no need for additional text. >=20 > One other approach is to open up that extension point for third-party > specifications. If we do this, we should be providing an IANA = registry, and > need to define the registration policy (RFC 8126). Theoretically, = this could be > done in a separate document, but the more usual way to do this is to = create > the registry in the document to which it applies. >=20 > If we create such a registry, what should be the registration policy? = How > easy should it be to create a control operator (and claim a name for = it)? > Section 4 of RFC 8126 proposes a number of potential policies. = Specification > Required (which is supported by a designated expert who decides = whether > there *is* a specification) seems to be the minimum requirement we = should > impose. On the other end of the spectrum, Standards Action means that > that specification must be an approved IETF standards track (or BCP) = RFC, > which is not that much different from not having a registry at all. = If we go for > RFC Required, the RFC could be Experimental or Informational, too. = Finally, > Expert Review is the most flexible policy, but then we should include = text > that guides the designated expert to make a decision. >=20 > To properly decide which of these approaches is right, we need a = crystal ball. > Creating too much latitude can fragment the language and create = uncertainty > whether a specification making use of a questionable extension = actually can > be used. Creating too much rigidity may be bad for the evolution of = the > language and for its ability to address evolving requirements. >=20 > I=E2=80=99m currently leaning towards creating a registry and giving = it Expert Review > policy, guiding the Designated Expert to accept registrations where a > specification is publicly available (Specification Required) and has = received > some community review, the result of which indicates that there is a = good > chance that independent implementations would achieve consistent > semantics. >=20 > That places a pretty big onus on the Designated Expert, whom = we=E2=80=99d need to > find once the CDDL RFC is approved. It is also more consensus = oriented than > a simple Specification Required but has less process than an IETF = Review or > Standards Action (both of which involve the IESG, which is a scarce = resource). > It does give the Designated Expert a lot of leeway to evolve the = details of the > handling of requests, which may be a good or a bad thing (in the = latter case, > the IESG can always replace the designated expert, but this is a = relatively > heavyweight procedure). >=20 > What do you think? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Jul 12 07:23:22 2018 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 E71D8131116; Thu, 12 Jul 2018 07:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 iynl8gB6id9B; Thu, 12 Jul 2018 07:23:16 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10044.outbound.protection.outlook.com [40.107.1.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242AD13110C; Thu, 12 Jul 2018 07:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Q6hENR525cQyqhs/qPhFvp7aiI1byAK4Ls5j6ps/Lw=; b=bJZo26RtomKO+2VmIhUoomtdaV5he4RC1/ZrinUVmtF3Sph8+LsnQdCqVqMM+J4J/Y50zDk0EWBrjW9Yay+aW9Wn9y+ZaSEP0OffsiXwmpVKGXfJyoYYKGarV4WJMo5ECRqJM5sZi3i7M6L939KSvd13Vprz4gg4oKgvQO2os2c= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2306.eurprd08.prod.outlook.com (10.172.218.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Thu, 12 Jul 2018 14:23:13 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::3c9f:d4ca:23a0:2aad]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::3c9f:d4ca:23a0:2aad%4]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 14:23:13 +0000 From: Brendan Moran To: Carsten Bormann CC: =?utf-8?B?w5h5dmluZCBSw7hubmluZ3N0YWQ=?= , suit , "cbor@ietf.org" Thread-Topic: [Suit] draft-moran-suit-manifest-02 Thread-Index: AdQTbk+t1KsTGeClRXioTvYSJXY/hwAaKKmAAYU6uQA= Date: Thu, 12 Jul 2018 14:23:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2306; 7:jIyWXU4Q101rkNxvG71dGWUtaB18kmSIzGTzTgRWb1lgJPKZ4z72KKAxK4sipdwHobK7W+zx0GZCr6KRR1O48cu4+THWZe1fzYU1E7yLo36WaHcjNrg7RuIq95TGxBwQDZcJ9yK8Dzd4kZ9mvezZd/Y2wVkRTnz58GoAKmcvQVc4k7Bcyc7h9JNO4CTO9TE6BPtx8Cicu+QtOxVdGc+4i+MRnYEIboMY+yb9mLPSBtSH17NzRig5oxlNPTOiO7oX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 55b364b9-ef43-4e9b-579b-08d5e8030064 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2306; x-ms-traffictypediagnostic: AM4PR0802MB2306: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(189930954265078)(223705240517415)(238713787762100); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2306; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2306; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(366004)(346002)(396003)(40434004)(51444003)(189003)(199004)(6916009)(36756003)(2906002)(50226002)(82746002)(6486002)(106356001)(6436002)(14454004)(6512007)(54896002)(14444005)(345774005)(5024004)(236005)(256004)(6506007)(102836004)(478600001)(53546011)(316002)(6246003)(3846002)(6116002)(26005)(186003)(83716003)(72206003)(54906003)(33656002)(105586002)(76176011)(57306001)(81156014)(486006)(68736007)(11346002)(446003)(81166006)(5250100002)(97736004)(476003)(53936002)(229853002)(86362001)(7736002)(25786009)(99286004)(66066001)(2900100001)(8676002)(8936002)(2616005)(4326008)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2306; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vMx3vfMULoUQoGYFb9f/5ozFU8s5cIpcWMnd23IveiV4S7Flyx1fSIb+ecAShHmSnWy5ZR0uXPC/FLZeaLjuCdLkQNErG1VC5bzxjJJgmPP6FU5mo93U5U06Gy+Bie5qw77foxJhyw4/rnVbuFUnAAyTPAoLpmKdrlaN/yDk66vN8pE1D0CKpNZqPBvZ+PXAAHoS+PNX5IzEYDdWteLqY7eflLhK0F1I2DbIwSp8S4Eq5vXuuUr1eYm6mE0tsON0E1I/WBbWF5RfqfnqZWghytLKKZYxTde/BcUrrDXxVm+ncyDHg7cITD4dLmqmjjgWzCDVv+zRnDQmb2sLNWT3etF63G2piRC6glqx/RzRS24= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F4C61E4F4FCD431B8423F65038F6F476armcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55b364b9-ef43-4e9b-579b-08d5e8030064 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 14:23:13.1114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2306 Archived-At: Subject: Re: [Cbor] [Suit] draft-moran-suit-manifest-02 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 14:23:21 -0000 --_000_F4C61E4F4FCD431B8423F65038F6F476armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMgQ2Fyc3RlbiBhbmQgw5h5dmluZC4gSSB0aGluayBJ IHN1Ym1pdHRlZCB0aGF0IGRyYWZ0IGluIHRvbyBtdWNoIG9mIGEgaHVycnkhDQoNCkRpcmVjdGl2 ZXMgYXJlIGludGVuZGVkIHRvIGhhbmRsZSBhIHNldCBvZiBwcm9ibGVtcyB0aGF0IGFyZSBlbnRp cmVseSBjb25zdHJhaW5lZCB0byB0aGUgYXBwbGljYXRpb24gb2YgdGhlIG1hbmlmZXN0LiBGb3Ig ZXhhbXBsZToNCg0KICAqICAgV2FpdCB1bnRpbCBiYXR0ZXJ5IGxldmVsIGlzIGFib3ZlIDUwJSBi ZWZvcmUgYXBwbHlpbmcgbWFuaWZlc3QgKG5vdGUgdGhhdCB0aGVyZSBpcyBhIHNpbWlsYXIgY29u ZGl0aW9uIGZvciBub24tZW5lcmd5IGhhcnZlc3RpbmcgYXBwbGljYXRpb25zKQ0KICAqICAgUmVi b290IGFmdGVyIGFwcGxpY2F0aW9uDQogICogICBSZXN0YXJ0IGRlc2lnbmF0ZWQgY29tcG9uZW50 IHdoZW4gaW5zdGFsbGF0aW9uIGlzIGNvbXBsZXRlDQogICogICBBcHBseSBvbmx5IGF0IDIzOjU5 IG9uIGEgU2F0dXJkYXkuDQogICogICBEaXNjb25uZWN0IGZyb20gdGhlIG5ldHdvcmsgcHJpb3Ig dG8gaW5zdGFsbGF0aW9uDQoNCk1lYW53aGlsZSwgZXh0ZW5zaW9ucyBhcmUgYSBwbGFjZWhvbGRl ciBmb3IgYWxsIHRob3NlIGNvbmNlcHRzIHRoYXQgd2UgaGF2ZW7igJl0IHJlYWxpc2VkIHdl4oCZ cmUgbWlzc2luZyB5ZXQuDQoNClRoZSBQcm9jZXNzaW5nU3RlcHMgbmVlZCB0byBoYXZlIG11bHRp cGxlIGlucHV0cy4gSSB0aGluayB0aGF0IGlub2RlIHNob3VsZCBiZSBhIGxpc3QgYW5kIG9ub2Rl IHNob3VsZCBiZSBzaW5nbGUuIFRoZW4sIGEgcHJvY2Vzc29yIGlzIHRoZSBhZ2dyZWdhdGUgb2Yg YSBtYXAgb2YgaW5wdXRzIGFuZCBhIHNpbmdsZSBvdXRwdXQuIEl0IG1heSBiZSB0aGF0IHRoaXMg aXMgbm90IGNvcnJlY3QgYW5kIHRoYXQgbXVsdGlwbGUgb25vZGVzIGFyZSBuZWVkZWQuDQoNCklm IGEgdGFyZ2V0IGlzIGFuIGFsaWFzLCB0aGF0IGltcGxpZXMgc2V2ZXJhbCB0aGluZ3M6DQoNCiAg KiAgIFRoZXJlIG11c3QgYmUgYW5vdGhlciB0YXJnZXQgd2l0aCB0aGUgc2FtZSBkaWdlc3QgaW4g YSBkZXBlbmRlbmN5IG1hbmlmZXN0DQogICogICBUaGUgdGFyZ2V0IGlzIG1pc3Npbmcgc2V2ZXJh bCBrZXkgcGllY2VzIG9mIGluZm9ybWF0aW9uOg0KICAgICAqICAgU2l6ZQ0KICAgICAqICAgQ29t cG9uZW50IElEDQogICAgICogICBTdG9yYWdlIGxvY2F0aW9uDQogICAgICogICBFbmNvZGluZw0K ICAqICAgVGhlIGNvbnRhaW5pbmcgbWFuaWZlc3QgZG9lc27igJl0IG5lZWQgdG8gaGF2ZSByaWdo dHMgdG8gaW5zdGFsbCB0aGUgdGFyZ2V0DQoNClRoZSBwb2ludCBvZiB0aGUgYWxpYXMgaXMgdG8g cmVkaXJlY3QgYSBjbGllbnQgdG8gZGlmZmVyZW50IGhvc3RpbmcgaW5mcmFzdHJ1Y3R1cmUgZm9y IGEgZ2l2ZW4gcGF5bG9hZC4NCg0KVGhlcmUgbXVzdCBiZSBhIHdheSB0byByZWZlcmVuY2UgdGhl IHJlc291cmNlcyBkZWNsYXJlZCBieSBkZXBlbmRlbmN5IG1hbmlmZXN0cy4gVGhlcmUgYXJlIHR3 byB3YXlzIHRoYXQgSSBjYW4gc2VlIHRvIGhhbmRsZSB0aGlzOg0KDQogIDEuICBVc2UgYXJiaXRy YXJ5IG5hbWVzICh0aGlzIGlzIHZ1bG5lcmFibGUgdG8gbm9kZS1uYW1lIGNvbGxpc2lvbnMpDQog IDIuICBVc2Ugbm9kZSBwYXRocyAodGhpcyBtYWtlcyBjcm9zcy1icmFuY2ggcmVmZXJlbmNlcyBt b3JlIGRpZmZpY3VsdCwgYnV0IEnigJltIG5vdCBjZXJ0YWluIHRoYXQgdGhvc2UgYXJlIGxlZ2l0 aW1hdGU6IGVhY2ggbWFuaWZlc3Qgc2hvdWxkIGRlY2xhcmUgaXRzIGRlcGVuZGVuY2llcyBleHBs aWNpdGx5OyBpZiB0aGF0IG1lYW5zIHRoZXJlIGFyZSBkdXBsaWNhdGUgbWFuaWZlc3RzIGluIGEg dHJlZSwgdGhhdCBpcyBhY2NlcHRhYmxlLikNCg0KSWYgbm9kZSBwYXRocyBhcmUgdXNlZCwgdGhl biBob3cgYXJlIHRoZXkgZW5jb2RlZD8gSSB3b3VsZCBzdXNwZWN0IHRoZXkgc2hvdWxkIGJlIENC T1IgYXJyYXlzLg0KDQpJ4oCZbGwgc2VlIHdoYXQgSSBjYW4gZG8gYWJvdXQgdGhvc2UgQ0RETCBw cm9ibGVtcyEgT25jZSBJIGhhdmUgYSBjaGFuY2UgdG8gdGFrZSBpbiBzb21lIG1vcmUgb2YgdGhl IGZlZWRiYWNrLCBJ4oCZbGwgc2VuZCBhIENEREwgZmlsZSB0aGF0IGVuY29tcGFzc2VzIHRoZXNl IGFuZCBtb3JlIHJlY29tbWVuZGF0aW9ucyBvdXQuDQoNClRoYW5rcywNCkJyZW5kYW4NCg0KT24g NCBKdWwgMjAxOCwgYXQgMjE6MzgsIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0 bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCg0KT24gSnVsIDQsIDIwMTgsIGF0IDEwOjI2LCBSw7hu bmluZ3N0YWQsIMOYeXZpbmQgPE95dmluZC5Sb25uaW5nc3RhZEBub3JkaWNzZW1pLm5vPG1haWx0 bzpPeXZpbmQuUm9ubmluZ3N0YWRAbm9yZGljc2VtaS5ubz4+IHdyb3RlOg0KPg0KPiAgICAgICAg 4oCiIENEREwgbml0cGlja2luZzoNCj4gICAgICAgICAgICAgICAg4oCiIFNvbWUgbmFtZSBpbmNv bnNpc3RlbmNpZXM6IFByb2Nlc3NpbmdTdGVwIHZzIFByb2Nlc3NvciwgVGFyZ2V0SW5mbyB2cyBU YXJnZXQuDQo+ICAgICAgICAgICAgICAgIOKAoiBUaGVyZSdzIHByb2JhYmx5IGEgdHlwbyBpbiB0 aGUgZGVmaW5pdGlvbiBvZiBEaXJlY3RpdmUuIFNob3VsZCBpdCBiZSBhbiBhcnJheSBvZiBtYXBz Pw0KPiAgICAgICAgICAgICAgICDigKIgVGFyZ2V0OjpzdG9yYWdlSWRlbnRpZmllciBhbmQgVGFy Z2V0Ojpjb21wb25lbnRJZGVudGlmaWVyIGRvbid0IHVzZSB0aGUgY3VzdG9tIHR5cGVzIGZvciBT dG9yYWdlSWRlbnRpZmllciBhbmQgQ29tcG9uZW50SWRlbnRpZmllci4NCj4gICAgICAgICAgICAg ICAg4oCiIEkgdGhpbmsgZGlnZXN0cyBzaG91bGQgaGF2ZSBhIHR5cGUsIHNvIHRoZSB1c2VyIGNh biBtb3JlIGVhc2lseSByZXN0cmljdCBpdHMgZm9ybWF0IGFmdGVyIGNob29zaW5nIGEgZGlnZXN0 IGFsZ29yaXRobS4NCj4gICAgICAgICAgICAgICAg4oCiIFN1Z2dlc3Rpb246IEFkZCBuaW50IHRv IHRleHRLZXlzIGdyb3VwLg0KPiAgICAgICAgICAgICAgICDigKIgQXV0aGVudGljYXRlZE1hbmlm ZXN0IHNob3VsZCBwcm9iYWJseSBjb250YWluIGFuIGF1dGhlbnRpY2F0ZWRNYW5pZmVzdFZlcnNp b24gb3Igc2ltaWxhci4NCj4gICAgICAgICAgICAgICAg4oCiICJQcm9jZXNzb3IiIG1pZ2h0IGJl IGNvbmZ1c2luZyAo4oCcZG9lcyBpdCBtZWFuIENQVT/igJ0pLg0KDQpJdCBhbHNvIGhlbHBzIHRv IG9jY2FzaW9uYWxseSBydW4gaW5zdGFuY2VzIG9mIGZvcm1hbCBsYW5ndWFnZXMgdGhyb3VnaCBz b21lIHRvb2wgdG8gY2hlY2sgdGhlbeKApg0KDQpBcGFydCBmcm9tIGluY29uc2lzdGVudCB1c2Ug b2YgbmFtZXMsIG1vc3Qgb2YgdGhlIHN5bnRheCBlcnJvcnMgc3RlbSBmcm9tIHRoZSBhcmNhbmUg c3ludGF4IHRoYXQgQ0RETCBpcyB1c2luZyBmb3IgaXRzIHdvcmthcm91bmQgZm9yIG5vdCBoYXZp bmcgdHJ1ZSBlbnVtZXJhdGlvbnMgKFNlY3Rpb24gMi4yLjIuMiBvZiBkcmFmdC1pZXRmLWNib3It Y2RkbC0wMy50eHQpOyB0aGlzIHJlcXVpcmVzIGNvbW1hcyAob3Igbm90aGluZykgaW5zdGVhZCBv ZiBzbGFzaGVzLCBhbmQgYW4gZW5jbG9zaW5nICYsIHNvIHdpdGggw5h5dmluZOKAmXMgc3VnZ2Vz dGlvbiwgdGV4dEtleXMgYmVjb21lcywgZS5nLjoNCg0KICB0ZXh0S2V5cyA9ICYoDQogICAgICB1 bmluaXRpYWxpc2VkOiAwDQogICAgICBtYW5pZmVzdERlc2NyaXB0aW9uOiAxDQogICAgICBwYXls b2FkRGVzY3JpcHRpb246IDINCiAgICAgIHZlbmRvck5hbWU6IDMNCiAgICAgIG1vZGVsTmFtZTog NA0KICAgICAgcGF5bG9hZFZlcnNpb246IDUNCiAgKSAvIG5pbnQNCg0KQW5kIFByb2Nlc3NvciBz dGFydHMgb2ZmIGFzOg0KDQogIFByb2Nlc3NvciAgICAgICA9IFsNCiAgICAgICYoZGVjcnlwdDog MSwgZGVjb21wcmVzczogMiwgdW5kaWZmOiAzLCByZWxvY2F0ZTogNCwgdW5yZWxvY2F0ZTogNSks DQoNCg0KKE9mIGNvdXJzZSwgdGhlIHNhbWUgdGhpbmcgY2FuIGJlIGV4cHJlc3NlZCBhczoNCg0K ICBQcm9jZXNzb3IgICAgICAgPSBbDQogICAgICAmKGRlY3J5cHQ6IDEsIGRlY29tcHJlc3M6IDIs IHVuZGlmZjogMywgcmVsb2NhdGU6IDQsIHVucmVsb2NhdGU6IDUpLA0KICAgICAgZGVjcnlwdDog MSAvLyBkZWNvbXByZXNzOiAyIC8vIHVuZGlmZjogMyAvLyByZWxvY2F0ZTogNCAvLyB1bnJlbG9j YXRlOiA1LA0KDQpOb3Qgc3VyZSB3aGF0IHRoZSBpbnRlbnQgaXMgaGVyZTsgaW4gdGhlIGZpcnN0 IGNhc2UsIEnigJlkIHByb2JhYmx5IGFsc28gYWRkIGEgbGFiZWwsIGFzIGluDQoNCiAgUHJvY2Vz c29yICAgICAgID0gWw0KICAgICAgcHJvY2VzczogJihkZWNyeXB0OiAxLCBkZWNvbXByZXNzOiAy LCB1bmRpZmY6IDMsIHJlbG9jYXRlOiA0LCB1bnJlbG9jYXRlOiA1KSwNCg0KSSBoYXZlIGF0dGFj aGVkIGEgdmVyc2lvbiB0aGF0IHBhcnNlcyAoSSBkb27igJl0IHRoaW5rIGFuIGF0dGFjaG1lbnQg d2lsbCBtYWtlIGl0IHRvIHRoZSBsaXN0cykgYnV0IGRvZXMgbm90IGFkZHJlc3MgYW55IG90aGVy IG9mIMOYeXZpbmTigJlzIHN1Z2dlc3Rpb25zLg0KDQpUaGUgb3RoZXIgcHJvYmxlbSB0aGF0IHNo b3VsZCBwcm9iYWJseSBiZSBhZGRyZXNzZWQgaXMgdGhhdCBtb3N0IHJ1bGVzIGFyZSB1bnVzZWQg 4oCUIHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgb25lIGNkZGwgZmlsZSBmb3IgdGhlIG1hbmlmZXN0 LCBhbmQgbWF5YmUgb25lIGZvciB0aGUgQ09TRSBlbnZlbG9wZS4gIFdlIHNpbXBseSBkb27igJl0 IGhhdmUgYSBnb29kIHdheSBpbiBDRERMIHlldCB0byBzYXkg4oCcTWFuaWZlc3QgZ29lcyB0aHJv dWdoIGFuIGFsZ29yaXRobSBhbmQgdHVybnMgdXAgaW4gQ09TRV9TaWdu4oCdIOKAlCBhY3R1YWxs eSwgaW4gdGhpcyBjYXNlIHRoaXMgY291bGQgYmUgc29sdmVkIGluIHBhcnQgYXMgdGhlIG1hbmlm ZXN0IHR1cm5zIHVwIGluIGNsZWFydGV6dC4NCkkgaGF2ZSBpbmNsdWRlZCBhIGRpcnR5IGhhY2sg aW4gdGhlIGF0dGFjaGVkIHdoaWNoIEkgaW50ZW5kIHRvIGZpeC4NCg0KSeKAmW0gQ0NpbmcgdGhl IENCT1IgV0cgdG8gZ2l2ZSBhbiBleGFtcGxlIGZvciBDRERMIGJlaW5nIHVzZWQgaW4gYW5vdGhl ciBXRy4gIElmIHlvdSB3YW50IHRvIGRpc2N1c3MgYSBDRERMIGZlYXR1cmUsIHBsZWFzZSBzdHJp a2UgU1VJVCBmcm9tIHRoZSBsaXN0IChhbmQgaWYgeW91IHdhbnQgdG8gZGlzY3VzcyBhIFNVSVQg ZmVhdHVyZSwgbWF5YmUgc3RyaWtlIENCT1IgZnJvbSB0aGUgbGlzdCkuDQoNCkdyw7zDn2UsIENh cnN0ZW4NCg0KDQoNCjxzdWl0LmNkZGw+DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== --_000_F4C61E4F4FCD431B8423F65038F6F476armcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzIENh cnN0ZW4gYW5kJm5ic3A7w5h5dmluZC4gSSB0aGluayBJIHN1Ym1pdHRlZCB0aGF0IGRyYWZ0IGlu IHRvbyBtdWNoIG9mIGEgaHVycnkhDQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGlyZWN0aXZlcyBhcmUgaW50ZW5kZWQg dG8gaGFuZGxlIGEgc2V0IG9mIHByb2JsZW1zIHRoYXQgYXJlIGVudGlyZWx5IGNvbnN0cmFpbmVk IHRvIHRoZSBhcHBsaWNhdGlvbiBvZiB0aGUgbWFuaWZlc3QuIEZvciBleGFtcGxlOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjx1bCBjbGFzcz0iTWFpbE91dGxpbmUiPg0KPGxpIGNsYXNzPSIiPldh aXQgdW50aWwgYmF0dGVyeSBsZXZlbCBpcyBhYm92ZSA1MCUgYmVmb3JlIGFwcGx5aW5nIG1hbmlm ZXN0IChub3RlIHRoYXQgdGhlcmUgaXMgYSBzaW1pbGFyIGNvbmRpdGlvbiBmb3Igbm9uLWVuZXJn eSBoYXJ2ZXN0aW5nIGFwcGxpY2F0aW9ucyk8L2xpPjxsaSBjbGFzcz0iIj5SZWJvb3QgYWZ0ZXIg YXBwbGljYXRpb248L2xpPjxsaSBjbGFzcz0iIj5SZXN0YXJ0IGRlc2lnbmF0ZWQgY29tcG9uZW50 IHdoZW4gaW5zdGFsbGF0aW9uIGlzIGNvbXBsZXRlPC9saT48bGkgY2xhc3M9IiI+QXBwbHkgb25s eSBhdCAyMzo1OSBvbiBhIFNhdHVyZGF5LjwvbGk+PGxpIGNsYXNzPSIiPkRpc2Nvbm5lY3QgZnJv bSB0aGUgbmV0d29yayBwcmlvciB0byBpbnN0YWxsYXRpb248L2xpPjwvdWw+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk1lYW53aGls ZSwgZXh0ZW5zaW9ucyBhcmUgYSBwbGFjZWhvbGRlciBmb3IgYWxsIHRob3NlIGNvbmNlcHRzIHRo YXQgd2UgaGF2ZW7igJl0IHJlYWxpc2VkIHdl4oCZcmUgbWlzc2luZyB5ZXQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgUHJvY2Vz c2luZ1N0ZXBzIG5lZWQgdG8gaGF2ZSBtdWx0aXBsZSBpbnB1dHMuIEkgdGhpbmsgdGhhdCBpbm9k ZSBzaG91bGQgYmUgYSBsaXN0IGFuZCBvbm9kZSBzaG91bGQgYmUgc2luZ2xlLiBUaGVuLCBhIHBy b2Nlc3NvciBpcyB0aGUgYWdncmVnYXRlIG9mIGEgbWFwIG9mIGlucHV0cyBhbmQgYSBzaW5nbGUg b3V0cHV0LiBJdCBtYXkgYmUgdGhhdCB0aGlzIGlzIG5vdCBjb3JyZWN0IGFuZCB0aGF0IG11bHRp cGxlIG9ub2Rlcw0KIGFyZSBuZWVkZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiBhIHRhcmdldCBpcyBhbiBhbGlhcywgdGhhdCBp bXBsaWVzIHNldmVyYWwgdGhpbmdzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjx1bCBjbGFzcz0i TWFpbE91dGxpbmUiPg0KPGxpIGNsYXNzPSIiPlRoZXJlIG11c3QgYmUgYW5vdGhlciB0YXJnZXQg d2l0aCB0aGUgc2FtZSBkaWdlc3QgaW4gYSBkZXBlbmRlbmN5IG1hbmlmZXN0PC9saT48bGkgY2xh c3M9IiI+VGhlIHRhcmdldCBpcyBtaXNzaW5nIHNldmVyYWwga2V5IHBpZWNlcyBvZiBpbmZvcm1h dGlvbjoNCjx1bCBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iIj5TaXplPC9saT48bGkgY2xhc3M9IiI+ Q29tcG9uZW50IElEPC9saT48bGkgY2xhc3M9IiI+U3RvcmFnZSBsb2NhdGlvbjwvbGk+PGxpIGNs YXNzPSIiPkVuY29kaW5nPC9saT48L3VsPg0KPC9saT48bGkgY2xhc3M9IiI+VGhlIGNvbnRhaW5p bmcgbWFuaWZlc3QgZG9lc27igJl0IG5lZWQgdG8gaGF2ZSByaWdodHMgdG8gaW5zdGFsbCB0aGUg dGFyZ2V0PC9saT48L3VsPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlIHBvaW50IG9mIHRoZSBhbGlhcyBpcyB0byByZWRpcmVjdCBhIGNsaWVu dCB0byBkaWZmZXJlbnQgaG9zdGluZyBpbmZyYXN0cnVjdHVyZSBmb3IgYSBnaXZlbiBwYXlsb2Fk LjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGVyZSBtdXN0IGJlIGEgd2F5IHRvIHJlZmVyZW5jZSB0aGUgcmVzb3VyY2Vz IGRlY2xhcmVkIGJ5IGRlcGVuZGVuY3kgbWFuaWZlc3RzLiBUaGVyZSBhcmUgdHdvIHdheXMgdGhh dCBJIGNhbiBzZWUgdG8gaGFuZGxlIHRoaXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPG9sIGNs YXNzPSJNYWlsT3V0bGluZSI+DQo8bGkgY2xhc3M9IiI+VXNlIGFyYml0cmFyeSBuYW1lcyAodGhp cyBpcyB2dWxuZXJhYmxlIHRvIG5vZGUtbmFtZSBjb2xsaXNpb25zKTwvbGk+PGxpIGNsYXNzPSIi PlVzZSBub2RlIHBhdGhzICh0aGlzIG1ha2VzIGNyb3NzLWJyYW5jaCByZWZlcmVuY2VzIG1vcmUg ZGlmZmljdWx0LCBidXQgSeKAmW0gbm90IGNlcnRhaW4gdGhhdCB0aG9zZSBhcmUgbGVnaXRpbWF0 ZTogZWFjaCBtYW5pZmVzdCBzaG91bGQgZGVjbGFyZSBpdHMgZGVwZW5kZW5jaWVzIGV4cGxpY2l0 bHk7IGlmIHRoYXQgbWVhbnMgdGhlcmUgYXJlIGR1cGxpY2F0ZSBtYW5pZmVzdHMgaW4gYSB0cmVl LCB0aGF0IGlzIGFjY2VwdGFibGUuKTwvbGk+PC9vbD4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgbm9kZSBwYXRocyBhcmUgdXNl ZCwgdGhlbiBob3cgYXJlIHRoZXkgZW5jb2RlZD8gSSB3b3VsZCBzdXNwZWN0IHRoZXkgc2hvdWxk IGJlIENCT1IgYXJyYXlzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+SeKAmWxsIHNlZSB3aGF0IEkgY2FuIGRvIGFib3V0IHRob3NlIENE REwgcHJvYmxlbXMhIE9uY2UgSSBoYXZlIGEgY2hhbmNlIHRvIHRha2UgaW4gc29tZSBtb3JlIG9m IHRoZSBmZWVkYmFjaywgSeKAmWxsIHNlbmQgYSBDRERMIGZpbGUgdGhhdCBlbmNvbXBhc3NlcyB0 aGVzZSBhbmQgbW9yZSByZWNvbW1lbmRhdGlvbnMgb3V0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5CcmVuZGFuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA0IEp1bCAyMDE4LCBhdCAyMToz OCwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiBjbGFz cz0iIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPk9u IEp1bCA0LCAyMDE4LCBhdCAxMDoyNiwgUsO4bm5pbmdzdGFkLCDDmHl2aW5kICZsdDs8YSBocmVm PSJtYWlsdG86T3l2aW5kLlJvbm5pbmdzdGFkQG5vcmRpY3NlbWkubm8iIGNsYXNzPSIiPk95dmlu ZC5Sb25uaW5nc3RhZEBub3JkaWNzZW1pLm5vPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAoiBDRERMIG5pdHBpY2tpbmc6PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKIgU29tZSBuYW1lIGluY29uc2lzdGVuY2llczog UHJvY2Vzc2luZ1N0ZXAgdnMgUHJvY2Vzc29yLCBUYXJnZXRJbmZvIHZzIFRhcmdldC48YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBUaGVyZSdz IHByb2JhYmx5IGEgdHlwbyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBEaXJlY3RpdmUuIFNob3VsZCBp dCBiZSBhbiBhcnJheSBvZiBtYXBzPzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsg4oCiIFRhcmdldDo6c3RvcmFnZUlkZW50aWZpZXIgYW5kIFRhcmdl dDo6Y29tcG9uZW50SWRlbnRpZmllciBkb24ndCB1c2UgdGhlIGN1c3RvbSB0eXBlcyBmb3IgU3Rv cmFnZUlkZW50aWZpZXIgYW5kIENvbXBvbmVudElkZW50aWZpZXIuPGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKIgSSB0aGluayBkaWdlc3RzIHNo b3VsZCBoYXZlIGEgdHlwZSwgc28gdGhlIHVzZXIgY2FuIG1vcmUgZWFzaWx5IHJlc3RyaWN0IGl0 cyBmb3JtYXQgYWZ0ZXIgY2hvb3NpbmcgYSBkaWdlc3QgYWxnb3JpdGhtLjxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIFN1Z2dlc3Rpb246IEFk ZCBuaW50IHRvIHRleHRLZXlzIGdyb3VwLjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCiIEF1dGhlbnRpY2F0ZWRNYW5pZmVzdCBzaG91bGQgcHJv YmFibHkgY29udGFpbiBhbiBhdXRoZW50aWNhdGVkTWFuaWZlc3RWZXJzaW9uIG9yIHNpbWlsYXIu PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKIg JnF1b3Q7UHJvY2Vzc29yJnF1b3Q7IG1pZ2h0IGJlIGNvbmZ1c2luZyAo4oCcZG9lcyBpdCBtZWFu IENQVT/igJ0pLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0IGFsc28gaGVscHMgdG8g b2NjYXNpb25hbGx5IHJ1biBpbnN0YW5jZXMgb2YgZm9ybWFsIGxhbmd1YWdlcyB0aHJvdWdoIHNv bWUgdG9vbCB0byBjaGVjayB0aGVt4oCmPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXBh cnQgZnJvbSBpbmNvbnNpc3RlbnQgdXNlIG9mIG5hbWVzLCBtb3N0IG9mIHRoZSBzeW50YXggZXJy b3JzIHN0ZW0gZnJvbSB0aGUgYXJjYW5lIHN5bnRheCB0aGF0IENEREwgaXMgdXNpbmcgZm9yIGl0 cyB3b3JrYXJvdW5kIGZvciBub3QgaGF2aW5nIHRydWUgZW51bWVyYXRpb25zIChTZWN0aW9uIDIu Mi4yLjIgb2YgZHJhZnQtaWV0Zi1jYm9yLWNkZGwtMDMudHh0KTsgdGhpcyByZXF1aXJlcyBjb21t YXMgKG9yIG5vdGhpbmcpIGluc3RlYWQgb2YNCiBzbGFzaGVzLCBhbmQgYW4gZW5jbG9zaW5nICZh bXA7LCBzbyB3aXRoIMOYeXZpbmTigJlzIHN1Z2dlc3Rpb24sIHRleHRLZXlzIGJlY29tZXMsIGUu Zy46PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7IHRleHRLZXlzID0gJmFtcDso PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuaW5pdGlhbGlz ZWQ6IDA8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuaWZl c3REZXNjcmlwdGlvbjogMTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBwYXlsb2FkRGVzY3JpcHRpb246IDI8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdmVuZG9yTmFtZTogMzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtb2RlbE5hbWU6IDQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGF5bG9hZFZlcnNpb246IDU8YnIgY2xhc3M9IiI+DQombmJzcDsg KSAvIG5pbnQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbmQgUHJvY2Vzc29yIHN0YXJ0 cyBvZmYgYXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7IFByb2Nlc3NvciZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA9IFs8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmFtcDsoZGVjcnlwdDogMSwgZGVjb21wcmVzczog MiwgdW5kaWZmOiAzLCByZWxvY2F0ZTogNCwgdW5yZWxvY2F0ZTogNSksPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKE9mIGNvdXJzZSwgdGhlIHNhbWUgdGhpbmcg Y2FuIGJlIGV4cHJlc3NlZCBhczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsg UHJvY2Vzc29yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gWzxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmYW1wOyhkZWNyeXB0OiAxLCBk ZWNvbXByZXNzOiAyLCB1bmRpZmY6IDMsIHJlbG9jYXRlOiA0LCB1bnJlbG9jYXRlOiA1KSw8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVjcnlwdDogMSAvLyBk ZWNvbXByZXNzOiAyIC8vIHVuZGlmZjogMyAvLyByZWxvY2F0ZTogNCAvLyB1bnJlbG9jYXRlOiA1 LDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vdCBzdXJlIHdoYXQgdGhlIGludGVudCBp cyBoZXJlOyBpbiB0aGUgZmlyc3QgY2FzZSwgSeKAmWQgcHJvYmFibHkgYWxzbyBhZGQgYSBsYWJl bCwgYXMgaW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgUHJvY2Vzc29yJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gWzxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm9jZXNzOiAmYW1wOyhkZWNyeXB0OiAxLCBkZWNv bXByZXNzOiAyLCB1bmRpZmY6IDMsIHJlbG9jYXRlOiA0LCB1bnJlbG9jYXRlOiA1KSw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgYXR0YWNoZWQgYSB2ZXJzaW9uIHRoYXQgcGFy c2VzIChJIGRvbuKAmXQgdGhpbmsgYW4gYXR0YWNobWVudCB3aWxsIG1ha2UgaXQgdG8gdGhlIGxp c3RzKSBidXQgZG9lcyBub3QgYWRkcmVzcyBhbnkgb3RoZXIgb2Ygw5h5dmluZOKAmXMgc3VnZ2Vz dGlvbnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIG90aGVyIHByb2JsZW0gdGhh dCBzaG91bGQgcHJvYmFibHkgYmUgYWRkcmVzc2VkIGlzIHRoYXQgbW9zdCBydWxlcyBhcmUgdW51 c2VkIOKAlCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIG9uZSBjZGRsIGZpbGUgZm9yIHRoZSBtYW5p ZmVzdCwgYW5kIG1heWJlIG9uZSBmb3IgdGhlIENPU0UgZW52ZWxvcGUuJm5ic3A7IFdlIHNpbXBs eSBkb27igJl0IGhhdmUgYSBnb29kIHdheSBpbiBDRERMIHlldCB0byBzYXkg4oCcTWFuaWZlc3Qg Z29lcyB0aHJvdWdoIGFuIGFsZ29yaXRobQ0KIGFuZCB0dXJucyB1cCBpbiBDT1NFX1NpZ27igJ0g 4oCUIGFjdHVhbGx5LCBpbiB0aGlzIGNhc2UgdGhpcyBjb3VsZCBiZSBzb2x2ZWQgaW4gcGFydCBh cyB0aGUgbWFuaWZlc3QgdHVybnMgdXAgaW4gY2xlYXJ0ZXp0LjxiciBjbGFzcz0iIj4NCkkgaGF2 ZSBpbmNsdWRlZCBhIGRpcnR5IGhhY2sgaW4gdGhlIGF0dGFjaGVkIHdoaWNoIEkgaW50ZW5kIHRv IGZpeC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ4oCZbSBDQ2luZyB0aGUgQ0JPUiBX RyB0byBnaXZlIGFuIGV4YW1wbGUgZm9yIENEREwgYmVpbmcgdXNlZCBpbiBhbm90aGVyIFdHLiZu YnNwOyBJZiB5b3Ugd2FudCB0byBkaXNjdXNzIGEgQ0RETCBmZWF0dXJlLCBwbGVhc2Ugc3RyaWtl IFNVSVQgZnJvbSB0aGUgbGlzdCAoYW5kIGlmIHlvdSB3YW50IHRvIGRpc2N1c3MgYSBTVUlUIGZl YXR1cmUsIG1heWJlIHN0cmlrZSBDQk9SIGZyb20gdGhlIGxpc3QpLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkdyw7zDn2UsIENhcnN0ZW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21lbnQi Pjxmb250IHNpemU9IjIiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJjaWQ6 NzEzMkNFNzcxNENFNzI0RTlDNDAyQ0RDRTY5NEQ1OTBAZXVycHJkMDgucHJvZC5vdXRsb29rLmNv bSI+Jmx0O3N1aXQuY2RkbCZndDs8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F4C61E4F4FCD431B8423F65038F6F476armcom_-- From nobody Fri Jul 13 18:01:49 2018 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 3E2D3130F53 for ; Fri, 13 Jul 2018 18:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iej-pVDWJVTI for ; Fri, 13 Jul 2018 18:01:45 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074F6130DC9 for ; Fri, 13 Jul 2018 18:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6E11fVM027092 for ; Sat, 14 Jul 2018 03:01:41 +0200 (CEST) Received: from dhcp-9193.meeting.ietf.org (dhcp-9193.meeting.ietf.org [31.133.145.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41SBFw5ZxtzDX4f; Sat, 14 Jul 2018 03:01:40 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 553222897.287753-c7dd5dc4f127245f01484075b65669b8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 13 Jul 2018 21:01:39 -0400 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 01:01:47 -0000 There is a discussion going on in the thread about Tag 1 that I'm not sure I understand. Since representation variants seem to play a big role in that discussion, I thought I should write up some background on representation variants in CBOR. (Paragraphs in parentheses are additional background information that can be skipped.) Gr=C3=BC=C3=9Fe, Carsten # Representation Variants in CBOR In CBOR, there is often more than one way to serialize a data model item. For instance, the unsigned integer value 1 can be represented as 0x01, 0x1801, 0x190001, 0x2000000001, 0x210000000000000001. (There are other approaches to this problem. For example, according to the encoding principles underlying UTF-8, the string "1" could be represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. UTF-8 [RFC3629] simply outlaws the longer representation variants, so there never is a choice. Another approach is to make the encoding non-redundant, as for instance with the CoAP option length [RFC7252]: The single-nibble encoding spans the values 0 to 12, the 1.5-byte encoding spans 13 to 268, and the 2.5-byte encoding spans 269 to 65804. As with the UTF-8 encoding rules, there is never a choice, but here there isn't even a need for code to check for outlawed values.) Consistent encoding (called canonicalization in RFC 7049) aims at a single defined serialization of a data model item. However, there is a cost to consistent encoding (in particular when maps are involved), so the basic mode of using CBOR does not employ consistent encoding. CBOR has been defined to enable very simple implementations for applications in very constrained environments. So it is relatively modest in its hard and fast requirements. However, there is an expectation that an implementation not targeted at very constrained environments (which we will call a full-function implementation here) at least: - accepts all representation variants (unless specifically told not to, e.g. when checking consistent encoding), and - only emits the shortest of multiple alternative representation variants for each data item. Today's implementations pretty much universally fulfill this expectation for integers, string lengths, container counts, and tags, but some do fall short for floating point values. (Even otherwise proficient programmers are often scared of floating point, or they may just not care about floating point values, or both. There is example code in the RFC, as well as in many of the 50+ CBOR implementations available as open source, so there is little excuse for chickening out on fully implementing floating point. Some implementation languages do make it harder than necessary to operate on floating point values, though -- implementers for those languages have this writer's sympathy.) A full-function implementation can decode any representation variant that a constrained implementation might generate. In the inverse direction, there may be some limitations on the constrained side that a CBOR-based protocol may want to make explicit: E.g., it could restrict integer values to 32-bit ranges (int32 OR uint32) or even 16 bits where that is possible. It could also do without 64-bit floating point where constrained implementations might be limited to 32-bit floating point libraries. (This is probably where the discussion of Tag 1 currently going on in the mailing list was touching representation variants first: 32-bit floating point is not generally very useful for 1970-epoch based times, but a full-function implementation sending a floating-point epoch-based time will generate a 32-bit representation if the time happens to fall on an integer multiple of currently 128 seconds.) At the data model level (where tags are defined, and where CDDL operates), such limitations only limit the range of values; a full-function generic encoder will then only generate the representation variants intended. A constrained encoder theoretically could be oblivious of this intent and, e.g., generate a 64-bit integer representation; most likely, these implementations are highly integrated between data model and serialization layers and thus will already do the right thing. (Theoretically, a constrained CBOR implementation could be written to only ever accept a specific representation variant that is not the shortest -- e.g. 0x190001 for the example above. This would limit interoperability considerably and therefore probably isn't a smart move.) CDDL does not have any language features to restrict representation variants, as it operates at the data model level. It does allow restricting the range of a value such that a full-function encoder would only use a certain subset of representation variants (e.g., float32 might be represented in 16-bit or 32-bit serialization, but never needs 64-bit serialization). However, there is no way to force a representation variant that is longer than the shortest one possible, and it is NOT RECOMMENDED to define CBOR protocols that would require doing so. (Yes, this also applies to floating point. While a high-speed encoder on a fast network might want to forego the couple of instructions needed for selection of the shortest encoding, the decoder should always be able to handle the shorter cases as well.) From nobody Sat Jul 14 10:37:32 2018 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 E2A75130EA2 for ; Sat, 14 Jul 2018 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZCl98pJSoUTi for ; Sat, 14 Jul 2018 10:37:24 -0700 (PDT) Received: from p3plsmtpa08-08.prod.phx3.secureserver.net (p3plsmtpa08-08.prod.phx3.secureserver.net [173.201.193.109]) (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 20726130E00 for ; Sat, 14 Jul 2018 10:37:24 -0700 (PDT) Received: from [192.168.2.61] ([76.69.234.166]) by :SMTPAUTH: with ESMTPSA id eOTyf7Ui0TeHseOTzfLwUC; Sat, 14 Jul 2018 10:37:23 -0700 From: Island Resort Message-Id: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A67C6543-C505-47C0-B07B-ABB4CBEB5F52" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sat, 14 Jul 2018 10:37:22 -0700 In-Reply-To: Cc: cbor@ietf.org To: Carsten Bormann References: X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfGTx5ErOCHSyZLfW3NrrZXUw7IwyoWfsu6656lfr4afyYejjFs27RoVeOwCzicbgGxbJBP9tn4LDZHeBZqj/duHfUOCJCvtyM5G/pucsjMfPpqJnfs3X YoXvqFN2+3qs9FxQFJCqBjIu+5c/wL6/+gW3d+AM1QkL0hMe13bDbrhlg0uOAjHQwqjiK5wUAFq9Mw== Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 17:37:31 -0000 --Apple-Mail=_A67C6543-C505-47C0-B07B-ABB4CBEB5F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Casrten, My pursuit here is approaches to create interoperable CBOR protocols and = how it relates to canonical encoding. Tag 1 is a side exploration and = example mostly towards that end. Neither of these are true, right? Canonicalization gives interoperability =E2=80=94 still need to specify = which types your protocol uses and a lot more Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation cost (It also turns out that canonicalization is not necessary for signing) Seems like CBOR could use formal conventions for creating interoperable = protocols. Something like this: 1) Fully specify protocol messages =E2=80=94 This could be done in CDDL = or in prose. Probably most protocols can be specified in CDDL. Those = that are in the most constrained environments might have to resort to = prose. This will (must) result in a clear list of data types that need = to be supported.=20 2) Specify the encoding rules =E2=80=94 This could be by requiring full = standard canonical encoding, or by picking and choosing from standard = canonical encoding rules or by specifying some custom encoding rules.=20 3) Specify max sizes =E2=80=94 This may be optional for most protocols, = but some need it. Sometimes it will be for individual fields, others for = messages. Once you have this specification, you pick the CBOR libraries that = support the types and encodings you need along with the code and heap = size constraints and other requirements. It=E2=80=99s less about current = CBOR library implementations, more about clear specs for interop. I=E2=80=99m not up to speed on CDDL yet, so I=E2=80=99m sure what=E2=80=99= s possible with it. To go on a bit further just on canonicalization, there are (only?) four = ways encoding can vary: 1) integers =E2=80=94 used either as a value or a length 2) indefinite vs definite lengths =E2=80=94 for strings, maps and arrays 3) map =E2=80=94 sorting order 4) float =E2=80=94 encoding of NaN and infinity Since there are only four, maybe we specify the canonical encoding for = each individually and precisely. A protocol can choose which they want = =C3=A0 la carte if they need to. Full canonical encoding would still be = preferred and a SHOULD. Each canonical encoding would be described tightly with MUSTs = conditional on whether it is providing canonical encoding support. For = example, =E2=80=9CIF canonical float encoding is implemented, NaN MUST = be expressed as 0xf97e00=E2=80=9D. The current language for float is = =E2=80=9Cmight need to=E2=80=A6=E2=80=9D. I=E2=80=99m here in Montreal and will be at the CBOR meeting. But maybe = you didn=E2=80=99t want to hear that. :-) LL > On Jul 13, 2018, at 6:01 PM, Carsten Bormann wrote: >=20 > There is a discussion going on in the thread about Tag 1 that I'm not > sure I understand. Since representation variants seem to play a big > role in that discussion, I thought I should write up some background > on representation variants in CBOR. >=20 > (Paragraphs in parentheses are additional background information that > can be skipped.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > # Representation Variants in CBOR >=20 > In CBOR, there is often more than one way to serialize a data model > item. >=20 > For instance, the unsigned integer value 1 can be represented as 0x01, > 0x1801, 0x190001, 0x2000000001, 0x210000000000000001. >=20 > (There are other approaches to this problem. For example, according > to the encoding principles underlying UTF-8, the string "1" could be > represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. UTF-8 [RFC3629] > simply outlaws the longer representation variants, so there never is a > choice. Another approach is to make the encoding non-redundant, as > for instance with the CoAP option length [RFC7252]: The single-nibble > encoding spans the values 0 to 12, the 1.5-byte encoding spans 13 to > 268, and the 2.5-byte encoding spans 269 to 65804. As with the UTF-8 > encoding rules, there is never a choice, but here there isn't even a > need for code to check for outlawed values.) >=20 > Consistent encoding (called canonicalization in RFC 7049) aims at a > single defined serialization of a data model item. >=20 > However, there is a cost to consistent encoding (in particular when > maps are involved), so the basic mode of using CBOR does not employ > consistent encoding. >=20 > CBOR has been defined to enable very simple implementations for > applications in very constrained environments. So it is relatively > modest in its hard and fast requirements. However, there is an > expectation that an implementation not targeted at very constrained > environments (which we will call a full-function implementation here) > at least: >=20 > - accepts all representation variants (unless specifically told not > to, e.g. when checking consistent encoding), and > - only emits the shortest of multiple alternative representation > variants for each data item. >=20 > Today's implementations pretty much universally fulfill this > expectation for integers, string lengths, container counts, and tags, > but some do fall short for floating point values. >=20 > (Even otherwise proficient programmers are often scared of floating > point, or they may just not care about floating point values, or both. > There is example code in the RFC, as well as in many of the 50+ CBOR > implementations available as open source, so there is little excuse > for chickening out on fully implementing floating point. Some > implementation languages do make it harder than necessary to operate > on floating point values, though -- implementers for those languages > have this writer's sympathy.) >=20 > A full-function implementation can decode any representation variant > that a constrained implementation might generate. In the inverse > direction, there may be some limitations on the constrained side that > a CBOR-based protocol may want to make explicit: E.g., it could > restrict integer values to 32-bit ranges (int32 OR uint32) or even 16 > bits where that is possible. It could also do without 64-bit floating > point where constrained implementations might be limited to 32-bit > floating point libraries. >=20 > (This is probably where the discussion of Tag 1 currently going on in > the mailing list was touching representation variants first: 32-bit > floating point is not generally very useful for 1970-epoch based > times, but a full-function implementation sending a floating-point > epoch-based time will generate a 32-bit representation if the time > happens to fall on an integer multiple of currently 128 seconds.) >=20 > At the data model level (where tags are defined, and where CDDL > operates), such limitations only limit the range of values; a > full-function generic encoder will then only generate the > representation variants intended. A constrained encoder theoretically > could be oblivious of this intent and, e.g., generate a 64-bit integer > representation; most likely, these implementations are highly > integrated between data model and serialization layers and thus will > already do the right thing. >=20 > (Theoretically, a constrained CBOR implementation could be written to > only ever accept a specific representation variant that is not the > shortest -- e.g. 0x190001 for the example above. This would limit > interoperability considerably and therefore probably isn't a smart > move.) >=20 > CDDL does not have any language features to restrict representation > variants, as it operates at the data model level. It does allow > restricting the range of a value such that a full-function encoder > would only use a certain subset of representation variants (e.g., > float32 might be represented in 16-bit or 32-bit serialization, but > never needs 64-bit serialization). However, there is no way to force > a representation variant that is longer than the shortest one > possible, and it is NOT RECOMMENDED to define CBOR protocols that > would require doing so. >=20 > (Yes, this also applies to floating point. While a high-speed encoder > on a fast network might want to forego the couple of instructions > needed for selection of the shortest encoding, the decoder should > always be able to handle the shorter cases as well.) >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_A67C6543-C505-47C0-B07B-ABB4CBEB5F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Casrten,

My pursuit here is approaches to create interoperable CBOR = protocols and how it relates to canonical encoding. Tag 1 is a side = exploration and example mostly towards that end.

Neither of these are true, = right?
  • Canonicalization gives interoperability =E2=80=94 still need = to specify which types your protocol uses and a lot more
  • Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation cost
  • (It also turns out that canonicalization is not necessary for = signing)

Seems like CBOR could use formal conventions for creating = interoperable protocols. Something like this:

1) Fully specify protocol = messages =E2=80=94 This could be done in CDDL or in prose. Probably most = protocols can be specified in CDDL. Those that are in the most = constrained environments might have to resort to prose. This will (must) = result in a clear list of data types that need to be = supported. 

2) Specify the encoding rules =E2=80=94 This could be by = requiring full standard canonical encoding, or by picking and choosing = from standard canonical encoding rules or by specifying some custom = encoding rules. 

3) Specify max sizes =E2=80=94 This may be optional for most = protocols, but some need it. Sometimes it will be for individual fields, = others for messages.

Once you have this specification, you = pick the CBOR libraries that support the types and encodings you need = along with the code and heap size constraints and other requirements. = It=E2=80=99s less about current CBOR library implementations, more about = clear specs for interop.

I=E2=80=99m not up to speed on CDDL yet, so I=E2=80=99m sure = what=E2=80=99s possible with it.


To = go on a bit further just on canonicalization, there are (only?) four = ways encoding can vary:
1) = integers =E2=80=94 used either as a value or a length
2) indefinite vs definite lengths =E2=80=94 for strings, maps = and arrays
3) map =E2=80=94 sorting order
4) float =E2=80=94 encoding of NaN and = infinity

Since there are only four, maybe we specify the canonical = encoding for each individually and precisely. A protocol can choose = which they want =C3=A0 la carte if they need to. Full canonical encoding = would still be preferred and a SHOULD.

Each canonical encoding would be = described tightly with MUSTs conditional on whether it is providing = canonical encoding support. For example, =E2=80=9CIF canonical float = encoding is implemented, NaN MUST be expressed as 0xf97e00=E2=80=9D. = The current language for float is =E2=80=9Cmight need = to=E2=80=A6=E2=80=9D.


I=E2=80=99m here in = Montreal and will be at the CBOR meeting. But maybe you didn=E2=80=99t = want to hear that. :-)

LL




On Jul = 13, 2018, at 6:01 PM, Carsten Bormann <cabo@tzi.org> wrote:

There = is a discussion going on in the thread about Tag 1 that I'm not
sure I understand.  Since representation variants seem = to play a big
role in that discussion, I thought I should = write up some background
on representation variants in = CBOR.

(Paragraphs in parentheses are = additional background information that
can be skipped.)

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


# Representation Variants in CBOR

In CBOR, there is often more than one way to = serialize a data model
item.

For instance, the unsigned integer value 1 can be represented = as 0x01,
0x1801, 0x190001, 0x2000000001, = 0x210000000000000001.

(There are other = approaches to this problem.  For example, according
to = the encoding principles underlying UTF-8, the string "1" could be
represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. =  UTF-8 [RFC3629]
simply outlaws the longer = representation variants, so there never is a
choice. =  Another approach is to make the encoding non-redundant, as
for instance with the CoAP option length [RFC7252]: The = single-nibble
encoding spans the values 0 to 12, the = 1.5-byte encoding spans 13 to
268, and the 2.5-byte = encoding spans 269 to 65804.  As with the UTF-8
encoding rules, there is never a choice, but here there isn't = even a
need for code to check for outlawed values.)

Consistent encoding (called canonicalization = in RFC 7049) aims at a
single defined serialization of a = data model item.

However, there is a cost = to consistent encoding (in particular when
maps are = involved), so the basic mode of using CBOR does not employ
consistent encoding.

CBOR has = been defined to enable very simple implementations for
applications in very constrained environments.  So it is = relatively
modest in its hard and fast requirements. =  However, there is an
expectation that an = implementation not targeted at very constrained
environments= (which we will call a full-function implementation here)
at= least:

- accepts all representation = variants (unless specifically told not
 to, e.g. = when checking consistent encoding), and
- only emits the = shortest of multiple alternative representation
=  variants for each data item.

Today's = implementations pretty much universally fulfill this
expectation for integers, string lengths, container counts, = and tags,
but some do fall short for floating point = values.

(Even otherwise proficient = programmers are often scared of floating
point, or they = may just not care about floating point values, or both.
There is example code in the RFC, as well as in many of the = 50+ CBOR
implementations available as open source, so = there is little excuse
for chickening out on fully = implementing floating point.  Some
implementation = languages do make it harder than necessary to operate
on = floating point values, though -- implementers for those languages
have this writer's sympathy.)

A = full-function implementation can decode any representation variant
that a constrained implementation might generate.  In = the inverse
direction, there may be some limitations on = the constrained side that
a CBOR-based protocol may want = to make explicit: E.g., it could
restrict integer values = to 32-bit ranges (int32 OR uint32) or even 16
bits where = that is possible.  It could also do without 64-bit floating
point where constrained implementations might be limited to = 32-bit
floating point libraries.

(This is probably where the discussion of Tag 1 currently = going on in
the mailing list was touching representation = variants first: 32-bit
floating point is not generally = very useful for 1970-epoch based
times, but a = full-function implementation sending a floating-point
epoch-based time will generate a 32-bit representation if the = time
happens to fall on an integer multiple of currently = 128 seconds.)

At the data model level = (where tags are defined, and where CDDL
operates), such = limitations only limit the range of values; a
full-function = generic encoder will then only generate the
representation = variants intended.  A constrained encoder theoretically
could be oblivious of this intent and, e.g., generate a = 64-bit integer
representation; most likely, these = implementations are highly
integrated between data model = and serialization layers and thus will
already do the = right thing.

(Theoretically, a constrained = CBOR implementation could be written to
only ever accept a = specific representation variant that is not the
shortest = -- e.g. 0x190001 for the example above.  This would limit
interoperability considerably and therefore probably isn't a = smart
move.)

CDDL does not = have any language features to restrict representation
variants, as it operates at the data model level.  It = does allow
restricting the range of a value such that a = full-function encoder
would only use a certain subset of = representation variants (e.g.,
float32 might be = represented in 16-bit or 32-bit serialization, but
never = needs 64-bit serialization).  However, there is no way to force
a representation variant that is longer than the shortest = one
possible, and it is NOT RECOMMENDED to define CBOR = protocols that
would require doing so.

(Yes, this also applies to floating point.  While a = high-speed encoder
on a fast network might want to forego = the couple of instructions
needed for selection of the = shortest encoding, the decoder should
always be able to = handle the shorter cases as well.)


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

= --Apple-Mail=_A67C6543-C505-47C0-B07B-ABB4CBEB5F52-- From nobody Sat Jul 14 19:02:09 2018 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 C75EA130ECC for ; Sat, 14 Jul 2018 19:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TPPo6IlVq83W for ; Sat, 14 Jul 2018 19:02:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8225E130E6C for ; Sat, 14 Jul 2018 19:02:03 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 14 Jul 2018 18:58:25 -0700 From: Jim Schaad To: 'Island Resort' , 'Carsten Bormann' CC: References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> In-Reply-To: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> Date: Sat, 14 Jul 2018 22:01:51 -0400 Message-ID: <007a01d41bdf$ce2d76d0$6a886470$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01D41BBE.471DD2A0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLIfzXdqD17XquTswgVin1z14S7+QJmSIoeopOLbQA= X-Originating-IP: [107.18.132.214] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 02:02:08 -0000 ------=_NextPart_000_007B_01D41BBE.471DD2A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See comments in line =20 From: CBOR On Behalf Of Island Resort Sent: Saturday, July 14, 2018 1:37 PM To: Carsten Bormann Cc: cbor@ietf.org Subject: Re: [Cbor] Representation Variants in CBOR =20 Hi Casrten, =20 My pursuit here is approaches to create interoperable CBOR protocols and = how it relates to canonical encoding. Tag 1 is a side exploration and = example mostly towards that end. =20 Neither of these are true, right? * Canonicalization gives interoperability =E2=80=94 still need to = specify which types your protocol uses and a lot more [JLS] This is true but can come at a cost. Often times if you have a = byte integer always using the two byte encoding of an integer is simpler = but not canonical. ( 18XX ) * Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation cost [JLS] This statement is completely false. As an example an unsorted = map is legal and interoperable but definitely not canonical. * (It also turns out that canonicalization is not necessary for signing) [JLS] Due to the fact that we designed COSE that way, this is a true = statement. =20 Seems like CBOR could use formal conventions for creating interoperable = protocols. Something like this: =20 1) Fully specify protocol messages =E2=80=94 This could be done in CDDL = or in prose. Probably most protocols can be specified in CDDL. Those = that are in the most constrained environments might have to resort to = prose. This will (must) result in a clear list of data types that need = to be supported.=20 [JLS] Would not require a smallest length encoding if you only specified = CDDL. That would always need to be done in prose. This is also only a = true statement if there are no extension points which might have other = things put in later. =20 2) Specify the encoding rules =E2=80=94 This could be by requiring full = standard canonical encoding, or by picking and choosing from standard = canonical encoding rules or by specifying some custom encoding rules.=20 [JLS] Or just by saying do something reasonable. =20 3) Specify max sizes =E2=80=94 This may be optional for most protocols, = but some need it. Sometimes it will be for individual fields, others for = messages. =20 Once you have this specification, you pick the CBOR libraries that = support the types and encodings you need along with the code and heap = size constraints and other requirements. It=E2=80=99s less about current = CBOR library implementations, more about clear specs for interop. =20 I=E2=80=99m not up to speed on CDDL yet, so I=E2=80=99m sure = what=E2=80=99s possible with it. =20 =20 To go on a bit further just on canonicalization, there are (only?) four = ways encoding can vary: 1) integers =E2=80=94 used either as a value or a length [JLS] I have no idea of what you mean here. You can specify a value = range either in terms of values or number of bytes for the maximum = value. 2) indefinite vs definite lengths =E2=80=94 for strings, maps and arrays 3) map =E2=80=94 sorting order 4) float =E2=80=94 encoding of NaN and infinity [JLS] Lengths of encoded float in terms of bytes.=20 5) For types with multiple encodings, which one are you going to use. 6) Do you tag explicitly or implicitly. CWT uses implicit tagging for = encoding dates but allows both integer and floating point types. =20 Since there are only four, maybe we specify the canonical encoding for = each individually and precisely. A protocol can choose which they want = =C3=A0 la carte if they need to. Full canonical encoding would still be = preferred and a SHOULD. =20 Each canonical encoding would be described tightly with MUSTs = conditional on whether it is providing canonical encoding support. For = example, =E2=80=9CIF canonical float encoding is implemented, NaN MUST = be expressed as 0xf97e00=E2=80=9D. The current language for float is = =E2=80=9Cmight need to=E2=80=A6=E2=80=9D. =20 [JLS] For ASN.1, people almost never managed to get BER encoding messed = up. They got DER encoding messed up on a regular bases. This maps to = =E2=80=98Use reasonable encoding=E2=80=99 vs =E2=80=98Use canonical = encoding=E2=80=99. It was also far harder to deal with getting DER = encoding done on small devices and in very tight code due to the fact = that one often needed to encode multiple times to get the DER encoding = correct. =20 Jim =20 =20 I=E2=80=99m here in Montreal and will be at the CBOR meeting. But maybe = you didn=E2=80=99t want to hear that. :-) =20 LL =20 =20 =20 On Jul 13, 2018, at 6:01 PM, Carsten Bormann > wrote: =20 There is a discussion going on in the thread about Tag 1 that I'm not sure I understand. Since representation variants seem to play a big role in that discussion, I thought I should write up some background on representation variants in CBOR. (Paragraphs in parentheses are additional background information that can be skipped.) Gr=C3=BC=C3=9Fe, Carsten # Representation Variants in CBOR In CBOR, there is often more than one way to serialize a data model item. For instance, the unsigned integer value 1 can be represented as 0x01, 0x1801, 0x190001, 0x2000000001, 0x210000000000000001. (There are other approaches to this problem. For example, according to the encoding principles underlying UTF-8, the string "1" could be represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. UTF-8 [RFC3629] simply outlaws the longer representation variants, so there never is a choice. Another approach is to make the encoding non-redundant, as for instance with the CoAP option length [RFC7252]: The single-nibble encoding spans the values 0 to 12, the 1.5-byte encoding spans 13 to 268, and the 2.5-byte encoding spans 269 to 65804. As with the UTF-8 encoding rules, there is never a choice, but here there isn't even a need for code to check for outlawed values.) Consistent encoding (called canonicalization in RFC 7049) aims at a single defined serialization of a data model item. However, there is a cost to consistent encoding (in particular when maps are involved), so the basic mode of using CBOR does not employ consistent encoding. CBOR has been defined to enable very simple implementations for applications in very constrained environments. So it is relatively modest in its hard and fast requirements. However, there is an expectation that an implementation not targeted at very constrained environments (which we will call a full-function implementation here) at least: - accepts all representation variants (unless specifically told not to, e.g. when checking consistent encoding), and - only emits the shortest of multiple alternative representation variants for each data item. Today's implementations pretty much universally fulfill this expectation for integers, string lengths, container counts, and tags, but some do fall short for floating point values. (Even otherwise proficient programmers are often scared of floating point, or they may just not care about floating point values, or both. There is example code in the RFC, as well as in many of the 50+ CBOR implementations available as open source, so there is little excuse for chickening out on fully implementing floating point. Some implementation languages do make it harder than necessary to operate on floating point values, though -- implementers for those languages have this writer's sympathy.) A full-function implementation can decode any representation variant that a constrained implementation might generate. In the inverse direction, there may be some limitations on the constrained side that a CBOR-based protocol may want to make explicit: E.g., it could restrict integer values to 32-bit ranges (int32 OR uint32) or even 16 bits where that is possible. It could also do without 64-bit floating point where constrained implementations might be limited to 32-bit floating point libraries. (This is probably where the discussion of Tag 1 currently going on in the mailing list was touching representation variants first: 32-bit floating point is not generally very useful for 1970-epoch based times, but a full-function implementation sending a floating-point epoch-based time will generate a 32-bit representation if the time happens to fall on an integer multiple of currently 128 seconds.) At the data model level (where tags are defined, and where CDDL operates), such limitations only limit the range of values; a full-function generic encoder will then only generate the representation variants intended. A constrained encoder theoretically could be oblivious of this intent and, e.g., generate a 64-bit integer representation; most likely, these implementations are highly integrated between data model and serialization layers and thus will already do the right thing. (Theoretically, a constrained CBOR implementation could be written to only ever accept a specific representation variant that is not the shortest -- e.g. 0x190001 for the example above. This would limit interoperability considerably and therefore probably isn't a smart move.) CDDL does not have any language features to restrict representation variants, as it operates at the data model level. It does allow restricting the range of a value such that a full-function encoder would only use a certain subset of representation variants (e.g., float32 might be represented in 16-bit or 32-bit serialization, but never needs 64-bit serialization). However, there is no way to force a representation variant that is longer than the shortest one possible, and it is NOT RECOMMENDED to define CBOR protocols that would require doing so. (Yes, this also applies to floating point. While a high-speed encoder on a fast network might want to forego the couple of instructions needed for selection of the shortest encoding, the decoder should always be able to handle the shorter cases as well.) _______________________________________________ CBOR mailing list CBOR@ietf.org =20 https://www.ietf.org/mailman/listinfo/cbor =20 ------=_NextPart_000_007B_01D41BBE.471DD2A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See = comments in line

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Island = Resort
Sent: Saturday, July 14, 2018 1:37 PM
To: = Carsten Bormann <cabo@tzi.org>
Cc: = cbor@ietf.org
Subject: Re: [Cbor] Representation Variants in = CBOR

 

Hi = Casrten,

 

My pursuit here is approaches to create interoperable = CBOR protocols and how it relates to canonical encoding. Tag 1 is a side = exploration and example mostly towards that = end.

 

Neither of these are true, = right?

  • Canonicalization gives interoperability =E2=80=94 still = need to specify which types your protocol uses and a lot = more

[JLS] This is true but can come at a cost.=C2=A0 = Often times if you have a byte integer always using the two byte = encoding of an integer is simpler but not canonical.=C2=A0=C2=A0 (=C2=A0 = 18XX )

  • Canonicalization is necessary for interoperability = =E2=80=94 interoperable CBOR protocol can, and in some cases must, use = indefinite lengths and unsorted maps because of implementation = cost

[JLS] This statement is completely = false.=C2=A0=C2=A0 As an example an unsorted map is legal and = interoperable but definitely not canonical.

  • (It also turns out that canonicalization is not necessary = for signing)

[JLS] Due to the fact that we designed COSE that = way, this is a true statement.

 

Seems like CBOR could use formal conventions for = creating interoperable protocols. Something like = this:

 

1) Fully specify protocol messages =E2=80=94 This = could be done in CDDL or in prose. Probably most protocols can be = specified in CDDL. Those that are in the most constrained environments = might have to resort to prose. This will (must) result in a clear list = of data types that need to be supported. 

[JLS] Would not require = a smallest length encoding if you only specified CDDL.=C2=A0 That would = always need to be done in prose.=C2=A0 This is also only a true = statement if there are no extension points which might have other things = put in later.

 

2) Specify the encoding rules =E2=80=94 This could be = by requiring full standard canonical encoding, or by picking and = choosing from standard canonical encoding rules or by specifying some = custom encoding rules. 

[JLS] Or just by saying do something = reasonable.

 

3) Specify max sizes =E2=80=94 This may be optional = for most protocols, but some need it. Sometimes it will be for = individual fields, others for = messages.

 

Once you have this specification, you pick the CBOR = libraries that support the types and encodings you need along with the = code and heap size constraints and other requirements. It=E2=80=99s less = about current CBOR library implementations, more about clear specs for = interop.

 

I=E2=80=99m not up to speed on CDDL yet, so = I=E2=80=99m sure what=E2=80=99s possible with = it.

 

 

To go on a bit further just on canonicalization, there = are (only?) four ways encoding can = vary:

1) integers =E2=80=94 used either as a value or a = length

[JLS] I have no idea of what you mean = here.=C2=A0 You can specify a value range either in terms of values or = number of bytes for the maximum = value.

2) = indefinite vs definite lengths =E2=80=94 for strings, maps and = arrays

3) map =E2=80=94 = sorting order

4) float = =E2=80=94 encoding of NaN and infinity

[JLS] Lengths of encoded = float in terms of bytes.

5) For types with = multiple encodings, which one are you going to = use.

6) Do you tag explicitly or implicitly.=C2=A0 = CWT uses implicit tagging for encoding dates but allows both integer and = floating point types.

 

Since there are only four, maybe we specify the = canonical encoding for each individually and precisely. A protocol can = choose which they want =C3=A0 la carte if they need to. Full canonical = encoding would still be preferred and a = SHOULD.

 

Each canonical encoding would be described tightly = with MUSTs conditional on whether it is providing canonical encoding = support. For example, =E2=80=9CIF canonical float encoding is = implemented, NaN MUST be expressed as 0xf97e00=E2=80=9D. The = current language for float is =E2=80=9Cmight need = to=E2=80=A6=E2=80=9D.

 

[JLS] For ASN.1, people almost never managed to = get BER encoding messed up.=C2=A0 They got DER encoding messed up on a = regular bases.=C2=A0 This maps to =E2=80=98Use reasonable = encoding=E2=80=99 vs =E2=80=98Use canonical encoding=E2=80=99.=C2=A0 It = was also far harder to deal with getting DER encoding done on small = devices and in very tight code due to the fact that one often needed to = encode multiple times to get the DER encoding = correct.

 

Jim

 

 

I=E2=80=99m here in Montreal and will be at the CBOR = meeting. But maybe you didn=E2=80=99t want to hear that. = :-)

 

LL

 

 

 



On Jul 13, 2018, at 6:01 PM, Carsten Bormann <cabo@tzi.org> = wrote:

 

There is a discussion going on in the thread about Tag = 1 that I'm not
sure I understand.  Since representation variants = seem to play a big
role in that discussion, I thought I should write = up some background
on representation variants in = CBOR.

(Paragraphs in parentheses are additional background = information that
can be skipped.)

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


# Representation Variants in CBOR

In CBOR, = there is often more than one way to serialize a data = model
item.

For instance, the unsigned integer value 1 can be = represented as 0x01,
0x1801, 0x190001, 0x2000000001, = 0x210000000000000001.

(There are other approaches to this = problem.  For example, according
to the encoding principles = underlying UTF-8, the string "1" could be
represented as = 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1.  UTF-8 [RFC3629]
simply = outlaws the longer representation variants, so there never is = a
choice.  Another approach is to make the encoding = non-redundant, as
for instance with the CoAP option length [RFC7252]: = The single-nibble
encoding spans the values 0 to 12, the 1.5-byte = encoding spans 13 to
268, and the 2.5-byte encoding spans 269 to = 65804.  As with the UTF-8
encoding rules, there is never a = choice, but here there isn't even a
need for code to check for = outlawed values.)

Consistent encoding (called canonicalization in = RFC 7049) aims at a
single defined serialization of a data model = item.

However, there is a cost to consistent encoding (in = particular when
maps are involved), so the basic mode of using CBOR = does not employ
consistent encoding.

CBOR has been defined to = enable very simple implementations for
applications in very = constrained environments.  So it is relatively
modest in its = hard and fast requirements.  However, there is an
expectation = that an implementation not targeted at very constrained
environments = (which we will call a full-function implementation here)
at = least:

- accepts all representation variants (unless specifically = told not
 to, e.g. when checking consistent encoding), and
- = only emits the shortest of multiple alternative = representation
 variants for each data item.

Today's = implementations pretty much universally fulfill this
expectation for = integers, string lengths, container counts, and tags,
but some do = fall short for floating point values.

(Even otherwise proficient = programmers are often scared of floating
point, or they may just not = care about floating point values, or both.
There is example code in = the RFC, as well as in many of the 50+ CBOR
implementations available = as open source, so there is little excuse
for chickening out on fully = implementing floating point.  Some
implementation languages do = make it harder than necessary to operate
on floating point values, = though -- implementers for those languages
have this writer's = sympathy.)

A full-function implementation can decode any = representation variant
that a constrained implementation might = generate.  In the inverse
direction, there may be some = limitations on the constrained side that
a CBOR-based protocol may = want to make explicit: E.g., it could
restrict integer values to = 32-bit ranges (int32 OR uint32) or even 16
bits where that is = possible.  It could also do without 64-bit floating
point where = constrained implementations might be limited to 32-bit
floating point = libraries.

(This is probably where the discussion of Tag 1 = currently going on in
the mailing list was touching representation = variants first: 32-bit
floating point is not generally very useful = for 1970-epoch based
times, but a full-function implementation = sending a floating-point
epoch-based time will generate a 32-bit = representation if the time
happens to fall on an integer multiple of = currently 128 seconds.)

At the data model level (where tags are = defined, and where CDDL
operates), such limitations only limit the = range of values; a
full-function generic encoder will then only = generate the
representation variants intended.  A constrained = encoder theoretically
could be oblivious of this intent and, e.g., = generate a 64-bit integer
representation; most likely, these = implementations are highly
integrated between data model and = serialization layers and thus will
already do the right = thing.

(Theoretically, a constrained CBOR implementation could be = written to
only ever accept a specific representation variant that is = not the
shortest -- e.g. 0x190001 for the example above.  This = would limit
interoperability considerably and therefore probably = isn't a smart
move.)

CDDL does not have any language features = to restrict representation
variants, as it operates at the data model = level.  It does allow
restricting the range of a value such that = a full-function encoder
would only use a certain subset of = representation variants (e.g.,
float32 might be represented in 16-bit = or 32-bit serialization, but
never needs 64-bit serialization). =  However, there is no way to force
a representation variant that = is longer than the shortest one
possible, and it is NOT RECOMMENDED = to define CBOR protocols that
would require doing so.

(Yes, = this also applies to floating point.  While a high-speed = encoder
on a fast network might want to forego the couple of = instructions
needed for selection of the shortest encoding, the = decoder should
always be able to handle the shorter cases as = well.)


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

 

------=_NextPart_000_007B_01D41BBE.471DD2A0-- From nobody Sat Jul 14 19:18:40 2018 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 8B0A8130E67 for ; Sat, 14 Jul 2018 19:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OpPxVJlmW6Z for ; Sat, 14 Jul 2018 19:18:36 -0700 (PDT) Received: from p3plsmtpa12-03.prod.phx3.secureserver.net (p3plsmtpa12-03.prod.phx3.secureserver.net [68.178.252.232]) (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 DB33912426A for ; Sat, 14 Jul 2018 19:18:36 -0700 (PDT) Received: from [192.168.2.61] ([76.69.234.166]) by :SMTPAUTH: with ESMTPSA id eWcMfEwCJ45IEeWcNfCuaJ; Sat, 14 Jul 2018 19:18:35 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_675CD400-29F2-4691-8D76-F849045411D8" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sat, 14 Jul 2018 22:18:34 -0400 In-Reply-To: <007a01d41bdf$ce2d76d0$6a886470$@augustcellars.com> Cc: Carsten Bormann , cbor@ietf.org To: Jim Schaad References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <007a01d41bdf$ce2d76d0$6a886470$@augustcellars.com> X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfFDMbFYMLDi5FtmwECiVVFREMFTmLPQYD1pc9wmkQgZAuBak7tHsq+4OYCnhvPV7f1HOE6qy8Wel5K6z8KwxgLh91s3BpqVRDrqIMCUgwb8i77nAka9Q a506lE9deXfj961z6FPpeczB5p2WgpGVAEAnEvv0yorasr4fCSTZ4IxHa3XIpmkOv+br7nofw2nIbmDPz1kb5Hse8PoGQ9oo0JlIfyl8HloTHB+WCk6UQjtr Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 02:18:39 -0000 --Apple-Mail=_675CD400-29F2-4691-8D76-F849045411D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comment below > On Jul 14, 2018, at 10:01 PM, Jim Schaad = wrote: >=20 > See comments in line > =20 > From: CBOR > On = Behalf Of Island Resort > Sent: Saturday, July 14, 2018 1:37 PM > To: Carsten Bormann > > Cc: cbor@ietf.org > Subject: Re: [Cbor] Representation Variants in CBOR > =20 > Hi Casrten, > =20 > My pursuit here is approaches to create interoperable CBOR protocols = and how it relates to canonical encoding. Tag 1 is a side exploration = and example mostly towards that end. > =20 > Neither of these are true, right? > Canonicalization gives interoperability =E2=80=94 still need to = specify which types your protocol uses and a lot more > [JLS] This is true but can come at a cost. Often times if you have a = byte integer always using the two byte encoding of an integer is simpler = but not canonical. ( 18XX ) > Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation cost > [JLS] This statement is completely false. As an example an unsorted = map is legal and interoperable but definitely not canonical. I=E2=80=99m saying that both statements are false to show that = canonicalization is neither sufficient or necessary for = interoperability.=20 LL --Apple-Mail=_675CD400-29F2-4691-8D76-F849045411D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Comment below

On Jul 14, 2018, at 10:01 PM, = Jim Schaad <ietf@augustcellars.com> wrote:

See = comments in line
 
From: CBOR <cbor-bounces@ietf.org> On Behalf = Of Island = Resort
Sent: Saturday, July 14, 2018 = 1:37 PM
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org
Subject: Re: [Cbor] Representation = Variants in CBOR
 
Hi Casrten,
 
My pursuit here is approaches to create = interoperable CBOR protocols and how it relates to canonical encoding. = Tag 1 is a side exploration and example mostly towards that end.
 
Neither of these are true, right?
  • Canonicalization gives interoperability =E2=80=94 = still need to specify which types your protocol uses and a lot more
[JLS] This is true but can = come at a cost.  Often times if you have a byte integer always = using the two byte encoding of an integer is simpler but not = canonical.   (  18XX )
  • Canonicalization is = necessary for interoperability =E2=80=94 interoperable CBOR protocol = can, and in some cases must, use indefinite lengths and unsorted maps = because of implementation cost
[JLS] This statement is completely false.   As an = example an unsorted map is legal and interoperable but definitely not = canonical.

I=E2=80=99m saying that both statements are false = to show that canonicalization is neither sufficient or necessary for = interoperability. 

LL







= --Apple-Mail=_675CD400-29F2-4691-8D76-F849045411D8-- From nobody Sun Jul 15 03:20:46 2018 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 E4ECA130F4A for ; Sun, 15 Jul 2018 03:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mrRREhvQqrhs for ; Sun, 15 Jul 2018 03:20:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04947130F41 for ; Sun, 15 Jul 2018 03:20:40 -0700 (PDT) Received: from Jude (107.18.132.214) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 15 Jul 2018 03:17:07 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Carsten Bormann' , References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <007a01d41bdf$ce2d76d0$6a886470$@augustcellars.com> In-Reply-To: Date: Sun, 15 Jul 2018 06:20:34 -0400 Message-ID: <008f01d41c25$790f23b0$6b2d6b10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01D41C03.F1FE6E10" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLIfzXdqD17XquTswgVin1z14S7+QJmSIoeAP5y6y0BjM8NCqJ/wCJQ X-Originating-IP: [107.18.132.214] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 10:20:44 -0000 ------=_NextPart_000_0090_01D41C03.F1FE6E10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry, I missed the first line. =20 From: Laurence Lundblade =20 Sent: Saturday, July 14, 2018 10:19 PM To: Jim Schaad Cc: Carsten Bormann ; cbor@ietf.org Subject: Re: [Cbor] Representation Variants in CBOR =20 Comment below On Jul 14, 2018, at 10:01 PM, Jim Schaad > wrote: =20 See comments in line =20 From: CBOR < cbor-bounces@ietf.org> On = Behalf Of Island Resort Sent: Saturday, July 14, 2018 1:37 PM To: Carsten Bormann < cabo@tzi.org> Cc: cbor@ietf.org Subject: Re: [Cbor] Representation Variants in CBOR =20 Hi Casrten, =20 My pursuit here is approaches to create interoperable CBOR protocols and = how it relates to canonical encoding. Tag 1 is a side exploration and = example mostly towards that end. =20 Neither of these are true, right? * Canonicalization gives interoperability =E2=80=94 still need to = specify which types your protocol uses and a lot more [JLS] This is true but can come at a cost. Often times if you have a = byte integer always using the two byte encoding of an integer is simpler = but not canonical. ( 18XX ) * Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation cost [JLS] This statement is completely false. As an example an unsorted = map is legal and interoperable but definitely not canonical. =20 I=E2=80=99m saying that both statements are false to show that = canonicalization is neither sufficient or necessary for = interoperability.=20 =20 LL =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0090_01D41C03.F1FE6E10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sorry, I = missed the first line.

 

From: = Laurence Lundblade <lgl@island-resort.com>
Sent: = Saturday, July 14, 2018 10:19 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Carsten Bormann = <cabo@tzi.org>; cbor@ietf.org
Subject: Re: [Cbor] = Representation Variants in CBOR

 

Comment = below



On Jul 14, 2018, at 10:01 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

See comments in line

 

From: CBOR <cbor-bounces@ietf.org> On Behalf Of Island = Resort
Sent: Saturday, July 14, 2018 1:37 = PM
To: Carsten = Bormann <cabo@tzi.org>
Cc: cbor@ietf.org
Subject: Re: [Cbor] Representation = Variants in CBOR

 

Hi Casrten,

 

My pursuit here is approaches to create interoperable = CBOR protocols and how it relates to canonical encoding. Tag 1 is a side = exploration and example mostly towards that = end.

 

Neither of these are true, = right?

  • Canonicalization gives interoperability =E2=80=94 still need to = specify which types your protocol uses and a lot = more

[JLS] This is true but can come at a cost.  = Often times if you have a byte integer always using the two byte = encoding of an integer is simpler but not canonical.   (  = 18XX )

  • Canonicalization is necessary for interoperability =E2=80=94 = interoperable CBOR protocol can, and in some cases must, use indefinite = lengths and unsorted maps because of implementation = cost

[JLS] This statement is completely = false.   As an example an unsorted map is legal and = interoperable but definitely not = canonical.

 

I=E2=80=99m saying that both statements are false to = show that canonicalization is neither sufficient or necessary for = interoperability. 

 

LL

 

 

 

 

 

 

 

------=_NextPart_000_0090_01D41C03.F1FE6E10-- From nobody Mon Jul 16 08:03:51 2018 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 80A081310EB for ; Mon, 16 Jul 2018 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bdnoNoPKTQKe for ; Mon, 16 Jul 2018 08:03:39 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DC51310FD for ; Mon, 16 Jul 2018 08:03:39 -0700 (PDT) Received: from [192.168.2.61] ([76.69.234.166]) by :SMTPAUTH: with ESMTPSA id f52IfXPTO2Q5Sf52IfOxFA; Mon, 16 Jul 2018 08:03:39 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_C52EFED1-09A8-43A7-9D12-FD80AD622B81" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> Date: Mon, 16 Jul 2018 11:03:38 -0400 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfGwPLbg0yH5NKBX2t7oL1qPz4kYALc7Edmy30qJnFziL5Wlg9JH9dYya0xOtIkB2nwCWSlA2r2C5CypxWMNhsxiutg4Wb5ead+6uXNUoSkzEZdMc0yka 5Jqle9NBpwnY3r6S67wPShYDdTLpinnlT5kUVMCMnNb/EaVgJNONegFZ Archived-At: Subject: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:03:48 -0000 --Apple-Mail=_C52EFED1-09A8-43A7-9D12-FD80AD622B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seems to me that is it possible to have non-interoperable CWT or COSE = implementations that are fully compliant with the specs due to the = allowed CBOR encoding variations. A CWT sender could only send = indefinite lengths. A CWT receiver is not required to support indefinite = lengths. Similar for integer encoding.=20 This seems true for every CBOR protocol unless the protocol=E2=80=99s = specification addresses it. I suspect this hasn=E2=80=99t been a problem = much because most implementations send canonical and receive most = variants, but technically speaking it is a gap in the specifications. I created a PR for EAT that = should address it for EAT. I choose to put all the burden on the server. = The EAT server MUST support all the encoding variants. The client gets = to do what it wants since it could be a tiny constrained device.=20 Seems like the CBOR RFC should instruct CBOR protocol designer to put a = CBOR interoperability section in their specification. CWT could do = similar to EAT. I=E2=80=99m not sure what the right answer for COSE is.=20= LL --Apple-Mail=_C52EFED1-09A8-43A7-9D12-FD80AD622B81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Seems= to me that is it possible to have non-interoperable CWT or COSE = implementations that are fully compliant with the specs due to the = allowed CBOR encoding variations. A CWT sender could only send = indefinite lengths. A CWT receiver is not required to support indefinite = lengths.  Similar for integer encoding. 

This seems true for every CBOR protocol = unless the protocol=E2=80=99s specification addresses it. I suspect this = hasn=E2=80=99t been a problem much because most implementations send = canonical and receive most variants, but technically speaking it is a = gap in the specifications.

I created a PR for = EAT that should address it for EAT. I choose to put all the = burden on the server. The EAT server MUST support all the encoding = variants. The client gets to do what it wants since it could be a tiny = constrained device. 

Seems like the CBOR RFC should instruct CBOR protocol = designer to put a CBOR interoperability section = in their specification.  CWT could do similar to EAT. I=E2=80=99m = not sure what the right answer for COSE is. 
LL

= --Apple-Mail=_C52EFED1-09A8-43A7-9D12-FD80AD622B81-- From nobody Mon Jul 16 08:38:13 2018 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 9B363131139 for ; Mon, 16 Jul 2018 08:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OzUJEigWI9Xz for ; Mon, 16 Jul 2018 08:38:06 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 90E781310E3 for ; Mon, 16 Jul 2018 08:38:06 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 08:38:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,361,1526367600"; d="scan'208";a="57271841" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga008.jf.intel.com with ESMTP; 16 Jul 2018 08:36:49 -0700 Received: from tjmaciei-mobl1.localnet (10.254.10.23) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 08:36:49 -0700 From: Thiago Macieira To: CC: Laurence Lundblade Date: Mon, 16 Jul 2018 08:36:47 -0700 Message-ID: <36475787.A1FMtvlaSG@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.254.10.23] Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:38:12 -0000 On Monday, 16 July 2018 08:03:38 PDT Laurence Lundblade wrote: > Seems to me that is it possible to have non-interoperable CWT or COSE > implementations that are fully compliant with the specs due to the allowed > CBOR encoding variations. A CWT sender could only send indefinite lengths. > A CWT receiver is not required to support indefinite lengths. Similar for > integer encoding. I don't agree. If the protocol doesn't say "encoders must not use indefinit= e=20 length", then indefinite length is a possibility and decoders must be able = to=20 read it. Then they remove interoperable. > This seems true for every CBOR protocol unless the protocol=E2=80=99s spe= cification > addresses it. I suspect this hasn=E2=80=99t been a problem much because m= ost > implementations send canonical and receive most variants, but technically > speaking it is a gap in the specifications. I disagree. > I created a PR for EAT that > should address it for EAT. I choose to put all the burden on the server. > The EAT server MUST support all the encoding variants. The client gets to > do what it wants since it could be a tiny constrained device. That seems like a good compromise: put the burden on the bigger of the=20 devices. Which one that is (encoder or decoder) depends on the protocol in= =20 question. > Seems like the CBOR RFC should instruct CBOR protocol designer to put a C= BOR > interoperability section in their specification. CWT could do similar to > EAT. I=E2=80=99m not sure what the right answer for COSE is. That looks like a good recommendation. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 16 08:46:11 2018 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 149A71310C2 for ; Mon, 16 Jul 2018 08:46:06 -0700 (PDT) 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_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 M_nSYiPhuVty for ; Mon, 16 Jul 2018 08:46:04 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 62F22130EB0 for ; Mon, 16 Jul 2018 08:46:04 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 08:46:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,361,1526367600"; d="scan'208";a="75199359" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 16 Jul 2018 08:45:50 -0700 Received: from tjmaciei-mobl1.localnet (10.254.10.23) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 08:45:49 -0700 From: Thiago Macieira To: CC: Laurence Lundblade Date: Mon, 16 Jul 2018 08:45:48 -0700 Message-ID: <23570897.NA5rlAYIKQ@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <36475787.A1FMtvlaSG@tjmaciei-mobl1> References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <36475787.A1FMtvlaSG@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.10.23] Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 15:46:09 -0000 On Monday, 16 July 2018 08:36:47 PDT Thiago Macieira wrote: > I don't agree. If the protocol doesn't say "encoders must not use indefinite > length", then indefinite length is a possibility and decoders must be able > to read it. Then they remove interoperable. The last sentence didn't make sense due to typo. I meant to say: then they remain interoperable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 16 09:01:56 2018 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 637EC130E0D for ; Mon, 16 Jul 2018 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2exi7k8HjJVD for ; Mon, 16 Jul 2018 09:01:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D240130EC1 for ; Mon, 16 Jul 2018 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6GG1mUr007311; Mon, 16 Jul 2018 18:01:48 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:2816:5b73:9cb2:cca0] (unknown [IPv6:2001:67c:1232:144:2816:5b73:9cb2:cca0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Tp7b6TmpzDXV7; Mon, 16 Jul 2018 18:01:47 +0200 (CEST) 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: <23570897.NA5rlAYIKQ@tjmaciei-mobl1> Date: Mon, 16 Jul 2018 12:01:46 -0400 Cc: cbor@ietf.org, Laurence Lundblade X-Mao-Original-Outgoing-Id: 553449704.717901-5a7ed83a055a9633fc42225bb6b1f490 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <36475787.A1FMtvlaSG@tjmaciei-mobl1> <23570897.NA5rlAYIKQ@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 16:01:54 -0000 On Jul 16, 2018, at 11:45, Thiago Macieira = wrote: >=20 > On Monday, 16 July 2018 08:36:47 PDT Thiago Macieira wrote: >> I don't agree. If the protocol doesn't say "encoders must not use = indefinite >> length", then indefinite length is a possibility and decoders must be = able >> to read it. Then they remove interoperable. >=20 > The last sentence didn't make sense due to typo. I meant to say: then = they=20 > remain interoperable. Right. If a spec based on CBOR does not restrict representation = variants, then it doesn=E2=80=99t restrict them. We could be more = explicit about that. (See my recent message about representation = variants.) Apart from floating point, this hasn=E2=80=99t been a problem that I = have heard of from the CBOR community. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 11:37:49 2018 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 E3486130E74 for ; Mon, 16 Jul 2018 11:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VkLD7xIhDT-q for ; Mon, 16 Jul 2018 11:37:43 -0700 (PDT) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.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 D5FCC131189 for ; Mon, 16 Jul 2018 11:37:43 -0700 (PDT) Received: from dhcp-8d21.meeting.ietf.org ([31.133.141.33]) by :SMTPAUTH: with ESMTPSA id f8NSf6DS7MHMaf8NSfYHKY; Mon, 16 Jul 2018 11:37:43 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2E5AEF4B-8279-4B62-B807-0D2013CBFA73" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 16 Jul 2018 14:37:42 -0400 In-Reply-To: Cc: Thiago Macieira , cbor@ietf.org To: Carsten Bormann References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <36475787.A1FMtvlaSG@tjmaciei-mobl1> <23570897.NA5rlAYIKQ@tjmaciei-mobl1> X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfB5Ls0WepgNsscRQxTL6kBaVv5TTzSD7Xf+euEKgohXKi668crmi1ERwu2yq0vFC5EsXqSLBslaMM8EPmbeC7YhERIPLpLQyPdtrnV8LPOTxqhCrOd6h gkrDgOwU2Jd+XrCJ+F7mUzIDDaECqbeaqrCZrltZJguhDL69arPorv6Mm9CKa/LjzNUxEKU4BzYboVTdseCTEXjyWMCjoM9NMYshPhJ4VMb3wqtZgfNBHUdq Gg7ZHJxyM9UQlX6Ua/tjPA== Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:37:47 -0000 --Apple-Mail=_2E5AEF4B-8279-4B62-B807-0D2013CBFA73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 16, 2018, at 12:01 PM, Carsten Bormann wrote: >=20 > On Jul 16, 2018, at 11:45, Thiago Macieira = wrote: >>=20 >> On Monday, 16 July 2018 08:36:47 PDT Thiago Macieira wrote: >>> I don't agree. If the protocol doesn't say "encoders must not use = indefinite >>> length", then indefinite length is a possibility and decoders must = be able >>> to read it. Then they remove interoperable. >>=20 >> The last sentence didn't make sense due to typo. I meant to say: then = they=20 >> remain interoperable. >=20 > Right. If a spec based on CBOR does not restrict representation = variants, then it doesn=E2=80=99t restrict them. We could be more = explicit about that. (See my recent message about representation = variants.) For this to interop, the receiver MUST implement all encoding variants = unless a specification for a specific CBOR-based protocol says = otherwise.=20 The CBOR specification should be explicit about this. Some text in = section 3 should say something like: =E2=80=9CUnless the specification of a CBOR-based protocol explicitly = restricts the encoding variants used, the decoder MUST support all = encoding variants=E2=80=9D This seems fine for indefinite lengths and less-than-shortest integer = and length encoding that are easy to implement, but I=E2=80=99m less = sure about more exotic types like bignum, fractions and maybe even = floating point epoch time. If this rule includes these exotics, then = most every protocol specification should have a restriction section to = exclude these. LL --Apple-Mail=_2E5AEF4B-8279-4B62-B807-0D2013CBFA73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jul 16, 2018, at 12:01 PM, Carsten Bormann <cabo@tzi.org> = wrote:

On Jul 16, 2018, at 11:45, Thiago Macieira <thiago.macieira@intel.com> wrote:

On = Monday, 16 July 2018 08:36:47 PDT Thiago Macieira wrote:
I don't agree. If the = protocol doesn't say "encoders must not use indefinite
length", then indefinite length is a possibility and decoders = must be able
to read it. Then they remove = interoperable.

The last = sentence didn't make sense due to typo. I meant to say: then they
remain interoperable.

Right.  If a spec based on CBOR does not restrict = representation variants, then it doesn=E2=80=99t restrict them.  We = could be more explicit about that.  (See my recent message about = representation variants.)

For this to interop, the receiver MUST implement = all encoding variants unless a specification for a specific CBOR-based = protocol says otherwise. 

The = CBOR specification should be explicit about this. Some text in section 3 = should say something like:

=E2=80=9CUnless the specification of = a CBOR-based protocol explicitly restricts the encoding variants used, = the decoder MUST support all encoding variants=E2=80=9D

This seems fine for = indefinite lengths and less-than-shortest integer and length encoding = that are easy to implement, but I=E2=80=99m less sure about more exotic = types like bignum, fractions and maybe even floating point epoch time. =  If this rule includes these exotics, then most every protocol = specification should have a restriction section to exclude these.

LL


= --Apple-Mail=_2E5AEF4B-8279-4B62-B807-0D2013CBFA73-- From nobody Mon Jul 16 11:48:37 2018 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 EAA6C1311B7 for ; Mon, 16 Jul 2018 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zFr7jWa80ZEh for ; Mon, 16 Jul 2018 11:48:24 -0700 (PDT) Received: from vwp3261.webpack.hosteurope.de (vwp3261.webpack.hosteurope.de [IPv6:2a01:488:42:1000:57e6:2d0c::]) (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 86DC41311B3 for ; Mon, 16 Jul 2018 11:48:24 -0700 (PDT) Received: from dhcp-84b8.meeting.ietf.org ([31.133.132.184] helo=mail.ilsf.eu); authenticated by vwp3261.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ff8Xl-0004NE-Jc; Mon, 16 Jul 2018 20:48:21 +0200 Date: Mon, 16 Jul 2018 20:47:49 +0200 From: Michael Breuer To: cbor@ietf.org Message-ID: <20180716184748.GB15830@mail.ilsf.eu> Mail-Followup-To: cbor@ietf.org References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> <005501d419df$c3a726e0$4af574a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cQlQM4+toL5GdE5O" Content-Disposition: inline In-Reply-To: <005501d419df$c3a726e0$4af574a0$@augustcellars.com> X-Arbitrary-Number-Of-The-Day: 42 User-Agent: Mutt/1.9.4 (2018-02-28) X-bounce-key: webpack.hosteurope.de; michael.breuer@ilsf.de; 1531766904; f402de0a; X-HE-SMSGID: 1ff8Xl-0004NE-Jc Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 18:48:36 -0000 --cQlQM4+toL5GdE5O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline +1 Having versioning of the language rather than fragmentation by the use of extensions sounds much better to me. At least in this early stage of the CDDL language. Michael Jim Schaad wrote on 2018.07.12 14:56:32 +0200: > I would have a strong preference that this would be done via versioning of the language. It makes it much easier to say that I have a CDDL version X item checker rather than trying to say I have a CDDL checker that support the following set of extensions. > > Jim > --cQlQM4+toL5GdE5O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEnDoHcSetz6yGS6BSc8gBX8CBIJ4FAltM6EMACgkQc8gBX8CB IJ4lcg//Z/R30Ppd9gxPw75baRY9jKKr0SOmSuMH+k7bQlF+UW83XJGNWltYV/Vl Zh0d5KHt18nO0i9ZdWu6KvxUe0+2tcoD8ahbq5ciYT6K5/lNHwTCD87BSRyU9QO4 P1HjnhsjmTFgxcZlDnI34w1hNdpi7TKOXpiKWuwAyQA9wV6etRQWnCdnCIfdNJvI fBrHsI+l9FtwVuvbrst/Ddcs2s1Jh7h78sXr53WZnhAmTozCQ/rWfDvJAP1X1wx/ e8SbrmG7OnfyI3XONlFtGC29U9lusfVPlUMZAjMeK3Vx6lTv5RPg5hD9n/8MSiRl Cg5gSuodH7GAs194owC3ReoRkCuQKjVGmTV/zdFDkFJM7oy4YBd/gy5q0d68n9n+ YS27ZDssG7SVX6VfCPU8XXVqNUFPKNspGRNnC9EzfqXYvZlGG3viHjQCrN9skdnM OgsGx0Wtz2MFrQe9AGmI2DgiwbTmOmu0og37ujHDJV6M1NzzRh6hcVjx5dwdDn9O rD61edOgCRyuypxsF/1iKUuH1I3aE5M5Sc02P+QjjnIgXiublRxFNl96E6kNWFeE eM3+kSY/YdpQEGrbT2FX1vLDyVYB8qUrVBVfu+5IJ9xqyadX5GGevD+sJADO4IGx 7bGwBVcguJUNZre9HQINjeYWFFtMS9yBfdO76E4MPqtn5HqnXUI= =51ew -----END PGP SIGNATURE----- --cQlQM4+toL5GdE5O-- From nobody Mon Jul 16 12:06:54 2018 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 73BAB130FD9 for ; Mon, 16 Jul 2018 12:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK4wM3NpnWVu for ; Mon, 16 Jul 2018 12:06:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEE312F295 for ; Mon, 16 Jul 2018 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6GJ6jr9022794; Mon, 16 Jul 2018 21:06:45 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334] (unknown [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41TtF04Dh4zDXW4; Mon, 16 Jul 2018 21:06:44 +0200 (CEST) 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: <20180716184748.GB15830@mail.ilsf.eu> Date: Mon, 16 Jul 2018 15:06:43 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 553460801.265054-b1eceda2c535b161c66811f7f69493bf Content-Transfer-Encoding: quoted-printable Message-Id: <36DB629D-EA46-4564-8474-D23B448D3230@tzi.org> References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> <005501d419df$c3a726e0$4af574a0$@augustcellars.com> <20180716184748.GB15830@mail.ilsf.eu> To: Michael Breuer X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:06:53 -0000 Hi Jim, Michael, there are some assumptions in these answers that I=E2=80=99m not sure = everybody shares. First, the assumption seems to be that all control operations will be = generally useful. For the ones defined in the current WG draft, that has of course been = the intention. But we already have some requests from SDOs that have = their own binary data formats and want to ship these around in CBOR =E2=80= =94 they=E2=80=99d need some very specific controls that can specify the = shape of the contents of those byte strings. These would not = realistically become a part of the common version of CDDL. More generally, the development model assumed here can be described as = the Cathedral side in the =E2=80=9CCathedral vs. Bazaar=E2=80=9D = analogy: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar So far CDDL indeed has been developed in Cathedral style =E2=80=94 with = good input from its users, but centrally managed. But control operators = provide a way to open this up in an, er, controlled way, so we don=E2=80=99= t have to be stuck in a cathedral, but can have the best of both worlds: = a reasonably controlled development model for the language itself, and a = much more open model for the control operators. We can always bundle up control operators we like in future versions of = the language, so wanting =E2=80=9CCDDL 2.0=E2=80=9D as a shortcut for a = number of control operators is not an argument against a more open = handling of developing them. If development of CDDL continues in the IETF, we can of course develop = our own, generally applicable, well-honed control operators as well. We = are just sharing a registry with the general public (which would likely = not be zero-threshold, anyway). We can also import nice additions from = outside into future versions of the CDDL language specification. (This = all stays theoretical until other organizations do some development, = too, but as I said that is not unlikely.) One approach to encourage bringing control operator extensions to the = IETF would be to give external ones a separate namespace. But this = creates the =E2=80=9CX-Dash=E2=80=9D problem (RFC 6648) all over again: = Once we pull some of them in, we would want to change their names; more = likely, people would still continue to use the old names to be = compatible with the largest number of tools. So we probably shouldn=E2=80= =99t do that. Gr=C3=BC=C3=9Fe, Carsten > On Jul 16, 2018, at 14:47, Michael Breuer = wrote: >=20 > Signed PGP part > +1 >=20 > Having versioning of the language rather than fragmentation by the use > of extensions sounds much better to me. At least in this early stage = of > the CDDL language. >=20 > Michael >=20 > Jim Schaad wrote on 2018.07.12 14:56:32 = +0200: >> I would have a strong preference that this would be done via = versioning of the language. It makes it much easier to say that I have = a CDDL version X item checker rather than trying to say I have a CDDL = checker that support the following set of extensions. >>=20 >> Jim >>=20 >=20 >=20 From nobody Mon Jul 16 12:16:49 2018 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 3DF3012F295 for ; Mon, 16 Jul 2018 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcaLF00_TrSC for ; Mon, 16 Jul 2018 12:16:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421AB12785F for ; Mon, 16 Jul 2018 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6GJGdYH000328; Mon, 16 Jul 2018 21:16:39 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334] (unknown [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41TtSQ5y5wzDXW7; Mon, 16 Jul 2018 21:16:38 +0200 (CEST) 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: Mon, 16 Jul 2018 15:16:37 -0400 Cc: Thiago Macieira , cbor@ietf.org X-Mao-Original-Outgoing-Id: 553461395.47835-c94f2af351958dc96becc48b9bf051b9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <36475787.A1FMtvlaSG@tjmaciei-mobl1> <23570897.NA5rlAYIKQ@tjmaciei-mobl1> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:16:47 -0000 On Jul 16, 2018, at 14:37, Laurence Lundblade = wrote: >=20 > This seems fine for indefinite lengths and less-than-shortest integer = and length encoding that are easy to implement, but I=E2=80=99m less = sure about more exotic types like bignum, fractions and maybe even = floating point epoch time. =20 These are not really representation variants: they are visible at the = data model level. If you don=E2=80=99t want Bignums, don=E2=80=99t include them in the = specific data model. If you don=E2=80=99t want floating point times, instead of using the = prelude=E2=80=99s time =3D #6.1(number) you can define your own CDDL type such as itime =3D #6.1(int) Or even: =20 uitime =3D #6.1(uint) > If this rule includes these exotics, then most every protocol = specification should have a restriction section to exclude these. Recommending to always have this section is probably a good idea anyway, = but I=E2=80=99m pretty sure that this will be empty in many quite frugal = protocols. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 12:25:08 2018 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 74F4F130F00 for ; Mon, 16 Jul 2018 12:25:04 -0700 (PDT) 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_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 X74kwrxUPg6n for ; Mon, 16 Jul 2018 12:25:02 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 64FA212F18C for ; Mon, 16 Jul 2018 12:25:02 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 12:25:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,362,1526367600"; d="scan'208";a="56964403" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga007.jf.intel.com with ESMTP; 16 Jul 2018 12:24:28 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 12:24:27 -0700 From: Thiago Macieira To: CC: Laurence Lundblade Date: Mon, 16 Jul 2018 12:24:22 -0700 Message-ID: <2162842.f0bhrmzmnP@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:25:05 -0000 On Monday, 16 July 2018 11:37:42 PDT Laurence Lundblade wrote: > This seems fine for indefinite lengths and less-than-shortest integer and > length encoding that are easy to implement, but I=E2=80=99m less sure abo= ut more > exotic types like bignum, fractions and maybe even floating point epoch > time. If this rule includes these exotics, then most every protocol > specification should have a restriction section to exclude these. That's a good point, but like Carsten says, tagged content is not exactly t= he=20 same as the core encoding. Handling of bignums and bigfloats is very=20 implementation-specific and will often require specialised libraries (like= =20 GMP) to support them. Those won't be found in generic encoders and decoders. In any case, I recommend expanding the wording about the floating point wid= th=20 too. Support for 16-bit hardware floating point is not very widespread, so = it=20 often involves software conversion, which could be expensive. Similarly,=20 constrained devices may opt to have only single-precision floating point=20 emulation instead of single- and double-precision. Unlike the encoding=20 variants for numbers, those *can* be described in CDDL, but it wouldn't hur= t=20 to have some explicit text in the spec saying protocols may want to think=20 about this. =46inally, I don't know if this is worth discussing, but there's the questi= on of=20 the bit patterns for NaN and infinities. Should a protocol restrict what=20 encodings are allowed for those values? Or only when they are part of map=20 keys? =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 16 12:35:02 2018 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 70581130DD2 for ; Mon, 16 Jul 2018 12:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-FTdow1rDss for ; Mon, 16 Jul 2018 12:34:58 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9CF130DEB for ; Mon, 16 Jul 2018 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6GJYt0E014284; Mon, 16 Jul 2018 21:34:55 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334] (unknown [IPv6:2001:67c:1232:144:24ec:5a89:88fc:7334]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41TtsV40smzDXWG; Mon, 16 Jul 2018 21:34:54 +0200 (CEST) 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: <2162842.f0bhrmzmnP@tjmaciei-mobl1> Date: Mon, 16 Jul 2018 15:34:52 -0400 Cc: cbor@ietf.org, Laurence Lundblade X-Mao-Original-Outgoing-Id: 553462491.2852629-4c035fa09d8fcfc4c819461adafffaec Content-Transfer-Encoding: quoted-printable Message-Id: References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <2162842.f0bhrmzmnP@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:35:01 -0000 On Jul 16, 2018, at 15:24, Thiago Macieira = wrote: >=20 > Finally, I don't know if this is worth discussing, but there's the = question of=20 > the bit patterns for NaN and infinities. Should a protocol restrict = what=20 > encodings are allowed for those values? Or only when they are part of = map=20 > keys? Is there an ambiguity about infinities? NaN, indeed, is somewhat special. For canonical, we say (7049 3.9): If NaN is an allowed value, it must always be represented as = 0xf97e00. That is almost always a good idea for NaN in general. (Unless you are using NaN encoding=E2=80=A6 Do we want to cater for = that? It is not part of the generic data model.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 16 12:54:25 2018 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 6843F1311B6 for ; Mon, 16 Jul 2018 12:54:15 -0700 (PDT) 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_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 52NbuOhZCwdn for ; Mon, 16 Jul 2018 12:54:13 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 976281311B3 for ; Mon, 16 Jul 2018 12:54:13 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 12:54:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,362,1526367600"; d="scan'208";a="67466555" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga002.fm.intel.com with ESMTP; 16 Jul 2018 12:53:56 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jul 2018 12:53:48 -0700 From: Thiago Macieira To: CC: Carsten Bormann , Laurence Lundblade Date: Mon, 16 Jul 2018 12:53:47 -0700 Message-ID: <2417658.AlUVZmgfcW@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <85FEB148-D851-4ADB-8E8B-D86D7687EB6D@island-resort.com> <2162842.f0bhrmzmnP@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Interoperable CBOR protocol issue? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 19:54:24 -0000 On Monday, 16 July 2018 12:34:52 PDT Carsten Bormann wrote: > On Jul 16, 2018, at 15:24, Thiago Macieira =20 wrote: > > Finally, I don't know if this is worth discussing, but there's the > > question of the bit patterns for NaN and infinities. Should a protocol > > restrict what encodings are allowed for those values? Or only when they > > are part of map keys? >=20 > Is there an ambiguity about infinities? Oops, no, there isn't. Infinities always have zero significand, so there's= =20 only one bit pattern for each. > NaN, indeed, is somewhat special. >=20 > For canonical, we say (7049 3.9): >=20 > If NaN is an allowed value, it must always be represented as 0xf97e00. >=20 > That is almost always a good idea for NaN in general. >=20 > (Unless you are using NaN encoding=E2=80=A6 Do we want to cater for that= ? It is > not part of the generic data model.) The point is that the code that generated the NaN on the sender side may ha= ve=20 used a different bit pattern, like using signalling vs quiet NaN. The encod= er=20 may not have done the conversion to a strictly-controlled value, so this bi= t=20 pattern may end up sent. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 16 14:01:37 2018 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 9ED241311CA for ; Mon, 16 Jul 2018 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5s_mtBmj3MMh for ; Mon, 16 Jul 2018 14:01:31 -0700 (PDT) Received: from vwp3261.webpack.hosteurope.de (vwp3261.webpack.hosteurope.de [IPv6:2a01:488:42:1000:57e6:2d0c::]) (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 E43651311B5 for ; Mon, 16 Jul 2018 14:01:30 -0700 (PDT) Received: from dhcp-84b8.meeting.ietf.org ([31.133.132.184] helo=mail.ilsf.eu); authenticated by vwp3261.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ffAca-00077i-JG; Mon, 16 Jul 2018 23:01:28 +0200 Date: Mon, 16 Jul 2018 23:00:55 +0200 From: Michael Breuer To: cbor@ietf.org Message-ID: <20180716210054.GA70340@mail.ilsf.eu> Mail-Followup-To: cbor@ietf.org References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> <005501d419df$c3a726e0$4af574a0$@augustcellars.com> <20180716184748.GB15830@mail.ilsf.eu> <36DB629D-EA46-4564-8474-D23B448D3230@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8zVAax2BypCg8iLA" Content-Disposition: inline In-Reply-To: <36DB629D-EA46-4564-8474-D23B448D3230@tzi.org> X-Arbitrary-Number-Of-The-Day: 42 User-Agent: Mutt/1.9.4 (2018-02-28) X-bounce-key: webpack.hosteurope.de; michael.breuer@ilsf.de; 1531774890; cae92712; X-HE-SMSGID: 1ffAca-00077i-JG Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 21:01:36 -0000 --8zVAax2BypCg8iLA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hej Carsten, thanks for the detailed explanation. Not being that much into those other SDOs was the missing information. Considering this, creating a new iana reg= istry with expert review makes sense to me. Gr=C3=BC=C3=9Fe, Michael Carsten Bormann wrote on 2018.07.16 21:06:43 +0200: > Hi Jim, Michael, > > there are some assumptions in these answers that I=E2=80=99m not sure eve= rybody shares. > > First, the assumption seems to be that all control operations will be gen= erally useful. > For the ones defined in the current WG draft, that has of course been the= intention. But we already have some requests from SDOs that have their ow= n binary data formats and want to ship these around in CBOR =E2=80=94 they= =E2=80=99d need some very specific controls that can specify the shape of t= he contents of those byte strings. These would not realistically become a = part of the common version of CDDL. > > More generally, the development model assumed here can be described as th= e Cathedral side in the =E2=80=9CCathedral vs. Bazaar=E2=80=9D analogy: htt= ps://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar > So far CDDL indeed has been developed in Cathedral style =E2=80=94 with g= ood input from its users, but centrally managed. But control operators pro= vide a way to open this up in an, er, controlled way, so we don=E2=80=99t h= ave to be stuck in a cathedral, but can have the best of both worlds: a rea= sonably controlled development model for the language itself, and a much mo= re open model for the control operators. > > We can always bundle up control operators we like in future versions of t= he language, so wanting =E2=80=9CCDDL 2.0=E2=80=9D as a shortcut for a numb= er of control operators is not an argument against a more open handling of = developing them. > > If development of CDDL continues in the IETF, we can of course develop ou= r own, generally applicable, well-honed control operators as well. We are = just sharing a registry with the general public (which would likely not be = zero-threshold, anyway). We can also import nice additions from outside in= to future versions of the CDDL language specification. (This all stays the= oretical until other organizations do some development, too, but as I said = that is not unlikely.) > > One approach to encourage bringing control operator extensions to the IET= F would be to give external ones a separate namespace. But this creates th= e =E2=80=9CX-Dash=E2=80=9D problem (RFC 6648) all over again: Once we pull = some of them in, we would want to change their names; more likely, people w= ould still continue to use the old names to be compatible with the largest= number of tools. So we probably shouldn=E2=80=99t do that. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Jul 16, 2018, at 14:47, Michael Breuer wrot= e: > > > > +1 > > > > Having versioning of the language rather than fragmentation by the use > > of extensions sounds much better to me. At least in this early stage of > > the CDDL language. > > > > Michael > > > > Jim Schaad wrote on 2018.07.12 14:56:32 +0200: > >> I would have a strong preference that this would be done via versionin= g of the language. It makes it much easier to say that I have a CDDL versi= on X item checker rather than trying to say I have a CDDL checker that supp= ort the following set of extensions. > >> > >> Jim > >> --8zVAax2BypCg8iLA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEnDoHcSetz6yGS6BSc8gBX8CBIJ4FAltNB4EACgkQc8gBX8CB IJ4bXw//Z79hwpobIIvriHxuFVbCJH3Vy4RVkGJnD/KYvRbF5HuB4ZL20+54/JKT 7GzPu1BpfOSK+wOdeSWutyF+D7r8j6y5lPB8KSBLFxRk1Vjcxqvrve4/L7leccxB 7KdtNYLKgtPxx8lbPmJNPzXzWO0JULNLj7gSPILxr64JhZGbSuHfd5yHXvnZ7EBR BzZ41HawcXmtY2FjWdceNDVEJbOnQ8Ys3oRKKP0d52/PinE8C1IykF/op3KtxGcd 15zby2j/jLH00NKfCAOz65HMtIU9lXX7N8elqFOzQAuz6PCccuybrCuq0cPkuHcA WZFDV5HqgIePI31KGoggO4tVwFIxs3lQFueBQvVzufJcnOgYHQNIhjnEpnUMsjMq 4CbSQ3Dr4+K0VncVxN2lyS/KSMYNxzuQV5f68OWU05NtS352fudinDuEc7v4HkHE 0z/JauieLy55naMnxI3b/lZWTKfD7GycS8fsftoZE0LUSzyIcVTZM4LKnXuI/ocT J/7CLLLUZvIHjmdYWqUjyhaVrB7iIw2+eDgMKfwN5n3YSKFFv17I6BuzLDHr7xmJ +yX/WBPRNIYgeF7IM9U93lyS9TPjhqFx++I51a8Z4VJpOB0BXXeFRRkQL9UR28by P05MH6zB6dCPnJ241OnbD8iAcuk4nJJro2/eBLaviQ7lvpM7MPc= =V9Pp -----END PGP SIGNATURE----- --8zVAax2BypCg8iLA-- From nobody Tue Jul 17 08:30:24 2018 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 597E1130ED2 for ; Tue, 17 Jul 2018 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 T-9GOVrCFdIb for ; Tue, 17 Jul 2018 08:30:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3933130F18 for ; Tue, 17 Jul 2018 08:30:18 -0700 (PDT) Received: from Jude (31.133.140.188) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Jul 2018 08:26:43 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Michael Breuer' CC: References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> <005501d419df$c3a726e0$4af574a0$@augustcellars.com> <20180716184748.GB15830@mail.ilsf.eu> <36DB629D-EA46-4564-8474-D23B448D3230@tzi.org> In-Reply-To: <36DB629D-EA46-4564-8474-D23B448D3230@tzi.org> Date: Tue, 17 Jul 2018 11:30:11 -0400 Message-ID: <01fd01d41de3$0e7fb860$2b7f2920$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIGhlm0TnqyCDKRUz2qWzTTcRmakQIeaR1ZAbZzmsYBuTHFbKQCR3Kg X-Originating-IP: [31.133.140.188] Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 15:30:23 -0000 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Monday, July 16, 2018 3:07 PM > To: Michael Breuer > Cc: cbor@ietf.org > Subject: Re: [Cbor] Should CDDL have an IANA registry for control = operators? > (#17) >=20 > Hi Jim, Michael, >=20 > there are some assumptions in these answers that I=E2=80=99m not sure = everybody > shares. There is another assumption here that is not documented. Is there going = to be a push to do a CDDL 2.0 in a timely manner or is this the final = version of the specification. My answer would actually be different if = there are no plans to ever do an update. >=20 > First, the assumption seems to be that all control operations will be = generally > useful. > For the ones defined in the current WG draft, that has of course been = the > intention. But we already have some requests from SDOs that have = their own > binary data formats and want to ship these around in CBOR =E2=80=94 = they=E2=80=99d need > some very specific controls that can specify the shape of the contents = of those > byte strings. These would not realistically become a part of the = common > version of CDDL. Either they are all going to be generally useful, or they are going to = be so esoteric that not only do I not want them I don't even want to = know about them. This would be similar to all of the __foo type options = that show up in C compilers that I don't use and therefore have never = cared about. I would expect that there would be some pressure to = implement things in the registry even if they are esoteric. >=20 > More generally, the development model assumed here can be described as = the > Cathedral side in the =E2=80=9CCathedral vs. Bazaar=E2=80=9D analogy: > https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar > So far CDDL indeed has been developed in Cathedral style =E2=80=94 = with good input > from its users, but centrally managed. But control operators provide = a way to > open this up in an, er, controlled way, so we don=E2=80=99t have to be = stuck in a > cathedral, but can have the best of both worlds: a reasonably = controlled > development model for the language itself, and a much more open model = for > the control operators. >=20 > We can always bundle up control operators we like in future versions = of the > language, so wanting =E2=80=9CCDDL 2.0=E2=80=9D as a shortcut for a = number of control > operators is not an argument against a more open handling of = developing > them. And of course we would probably change the semantics some when doing = this so there are going to be multiple copies of these operators anyway. >=20 > If development of CDDL continues in the IETF, we can of course develop = our > own, generally applicable, well-honed control operators as well. We = are just > sharing a registry with the general public (which would likely not be = zero- > threshold, anyway). We can also import nice additions from outside = into future > versions of the CDDL language specification. (This all stays = theoretical until > other organizations do some development, too, but as I said that is = not > unlikely.) >=20 > One approach to encourage bringing control operator extensions to the = IETF > would be to give external ones a separate namespace. But this creates = the =E2=80=9CX- > Dash=E2=80=9D problem (RFC 6648) all over again: Once we pull some of = them in, we > would want to change their names; more likely, people would still = continue to > use the old names to be compatible with the largest number of tools. = So we > probably shouldn=E2=80=99t do that. Being compatible with the largest number of tools implies that these are = things which should be done in an updated version of the specification = rather than being esoteric things that are one offs. Jim >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Jul 16, 2018, at 14:47, Michael Breuer = wrote: > > > > Signed PGP part > > +1 > > > > Having versioning of the language rather than fragmentation by the = use > > of extensions sounds much better to me. At least in this early stage > > of the CDDL language. > > > > Michael > > > > Jim Schaad wrote on 2018.07.12 14:56:32 = +0200: > >> I would have a strong preference that this would be done via = versioning of > the language. It makes it much easier to say that I have a CDDL = version X item > checker rather than trying to say I have a CDDL checker that support = the > following set of extensions. > >> > >> Jim > >> > > > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 17 10:55:10 2018 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 0080613104C for ; Tue, 17 Jul 2018 10:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aE-FMCjCrA7M for ; Tue, 17 Jul 2018 10:54:58 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E499E13104B for ; Tue, 17 Jul 2018 10:54:57 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1634227505; Tue, 17 Jul 2018 13:54:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <005501d419df$c3a726e0$4af574a0$@augustcellars.com> Date: Tue, 17 Jul 2018 13:54:53 -0400 Cc: Carsten Bormann , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <28BD8519-7EF0-4EAA-A1FF-F466460E48EF@seantek.com> References: <1D56B4AD-F536-4DED-B2A4-34BEDD9B2FB6@tzi.org> <005501d419df$c3a726e0$4af574a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators? (#17) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:55:07 -0000 +1 to Jim=E2=80=99s comment. I remain skeptical about the actual utility of control operators in = defining specifications. Accordingly, I am opposed to creating a = registry. If people use control operators in specs and later want to change or = expand the range of acceptable values, they will regret putting the = control operator in there in the first place.=20 It is better to leave it as a free-for-all for now, which is to say, the = text of cddl-02 (no registry) was better than cddl-03 (proposed IANA = registry). Sean > On Jul 12, 2018, at 8:56 AM, Jim Schaad = wrote: >=20 > I would have a strong preference that this would be done via = versioning of the language. It makes it much easier to say that I have = a CDDL version X item checker rather than trying to say I have a CDDL = checker that support the following set of extensions. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: CBOR On Behalf Of Carsten Bormann >> Sent: Thursday, July 12, 2018 12:07 AM >> To: cbor@ietf.org >> Subject: [Cbor] Should CDDL have an IANA registry for control = operators? >> (#17) >>=20 >> To provide extensibility, CDDL provides one major extension point: = control >> operators. >>=20 >> However, the current text does not define how to actually add a = control >> operator. >>=20 >> One approach is that this extension point is there just for evolution = of the >> language, so any new control operators would be defined by a CDDL = 1.1 or >> 2.0 document. In this case, there is no need for additional text. >>=20 >> One other approach is to open up that extension point for third-party >> specifications. If we do this, we should be providing an IANA = registry, and >> need to define the registration policy (RFC 8126). Theoretically, = this could be >> done in a separate document, but the more usual way to do this is to = create >> the registry in the document to which it applies. >>=20 >> If we create such a registry, what should be the registration policy? = How >> easy should it be to create a control operator (and claim a name for = it)? >> Section 4 of RFC 8126 proposes a number of potential policies. = Specification >> Required (which is supported by a designated expert who decides = whether >> there *is* a specification) seems to be the minimum requirement we = should >> impose. On the other end of the spectrum, Standards Action means = that >> that specification must be an approved IETF standards track (or BCP) = RFC, >> which is not that much different from not having a registry at all. = If we go for >> RFC Required, the RFC could be Experimental or Informational, too. = Finally, >> Expert Review is the most flexible policy, but then we should include = text >> that guides the designated expert to make a decision. >>=20 >> To properly decide which of these approaches is right, we need a = crystal ball. >> Creating too much latitude can fragment the language and create = uncertainty >> whether a specification making use of a questionable extension = actually can >> be used. Creating too much rigidity may be bad for the evolution of = the >> language and for its ability to address evolving requirements. >>=20 >> I=E2=80=99m currently leaning towards creating a registry and giving = it Expert Review >> policy, guiding the Designated Expert to accept registrations where a >> specification is publicly available (Specification Required) and has = received >> some community review, the result of which indicates that there is a = good >> chance that independent implementations would achieve consistent >> semantics. >>=20 >> That places a pretty big onus on the Designated Expert, whom we=E2=80=99= d need to >> find once the CDDL RFC is approved. It is also more consensus = oriented than >> a simple Specification Required but has less process than an IETF = Review or >> Standards Action (both of which involve the IESG, which is a scarce = resource). >> It does give the Designated Expert a lot of leeway to evolve the = details of the >> handling of requests, which may be a good or a bad thing (in the = latter case, >> the IESG can always replace the designated expert, but this is a = relatively >> heavyweight procedure). >>=20 >> What do you think? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 17 12:01:02 2018 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 2E40C1310BA for ; Tue, 17 Jul 2018 12:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 g0mgwDymokif for ; Tue, 17 Jul 2018 12:00:50 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868D4131041 for ; Tue, 17 Jul 2018 12:00:39 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1613827513; Tue, 17 Jul 2018 15:00:37 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Jul 2018 15:00:35 -0400 References: To: Pete Cordell , cbor@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 19:01:01 -0000 I was going through the mailing list and saw this proposal. I think it = is a reasonable proposal. I do not think it replaces the need for = .regexp but it is a good illustration of a proposed control operator = that has utility (i.e., as an alternative, not an alternate, to = .regexp). Your proposal would be better if it is simply: ".abnf" S elements CRLF where elements is the rule defined in RFC 5234. The broader point here relates to how to add control operators to CDDL. = I think this illustrates a point that the value following the control = operator needs to be specified in relation to the control operator ID. = It does not make sense to say type1 .ge "foo" as that would be a syntax error; only=20 type1 .ge 6.3 (i.e., numbers) are valid. Sean > On Mar 30, 2018, at 8:09 AM, Pete Cordell = wrote: >=20 > Thinking laterally, if specifying a regex format is problematic, is it = worth considering ABNF as an alternative? >=20 > The pipe character could act as a suitable delimiter. For example: >=20 > triple-digit =3D tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT | >=20 > Over multiple lines it could look like: >=20 > triple-digit =3D tstr .abnf | > 1*DIGIT "." 1*DIGIT "." 1*DIGIT > | >=20 > The ABNF could be loosely defined; as in: >=20 > opague-abnf =3D *( text / NOT-PIPE ) > NOT-PIPE =3D CRLF / %x20-5B / %x7D-10FFFD >=20 > It's more verbose. And it's unconventional. But... >=20 > Pete. > --=20 > --------------------------------------------------------------------- > Pete Cordell > http://json-content-rules.org Rule > --------------------------------------------------------------------- >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 17 13:55:07 2018 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 5AA59129C6B for ; Tue, 17 Jul 2018 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxS0iTieQN6D for ; Tue, 17 Jul 2018 13:54:58 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5D6130DC2 for ; Tue, 17 Jul 2018 13:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6HKssi9002820; Tue, 17 Jul 2018 22:54:54 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:4885:f187:a964:83ad] (unknown [IPv6:2001:67c:1232:144:4885:f187:a964:83ad]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41VXbL0CLCzDXks; Tue, 17 Jul 2018 22:54:53 +0200 (CEST) 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: Tue, 17 Jul 2018 16:54:52 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 553553690.537215-78a46b0e809aee8275c46e394063b2ec Content-Transfer-Encoding: quoted-printable Message-Id: <46C63155-C2AB-4DBF-9348-3D42782A452E@tzi.org> References: To: Pete Cordell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 20:55:04 -0000 Hi Pete, Mixing in ABNF into CDDL is still something I=E2=80=99d like to do (for = 2.0). A simple control like the .abnf you used in March is not enough, since = most ABNF right hand sides require one or more rules to become useful. = In this case, DIGIT (even if that happens to be a core rule =E2=80=94 = you still have to provide it). A good place to keep those additional = rules hasn=E2=80=99t occurred to me. Also, it would be nice for this to have an equivalent of Python=E2=80=99s = =E2=80=9C=E2=80=9D=E2=80=9D for this =E2=80=94 you used | (which would = be quite confusing for people that think in classic BNF). Ugly straw man: maybe something like triple-digit =3D text .abnf =E2=80=9C=E2=80=9D=E2=80=9D 1*DIGIT = 2*(=E2=80=9C.=E2=80=9D 1*DIGIT) DIGIT =3D %x30-39 =E2=80=9C=E2=80=9D=E2=80=9D (i.e., the first line of the string is used as the RHS for an anonymous = ABNF rule, the others provide additional rules.) Gr=C3=BC=C3=9Fe, Carsten > On Mar 30, 2018, at 08:09, Pete Cordell = wrote: >=20 > Thinking laterally, if specifying a regex format is problematic, is it = worth considering ABNF as an alternative? >=20 > The pipe character could act as a suitable delimiter. For example: >=20 > triple-digit =3D tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT | >=20 > Over multiple lines it could look like: >=20 > triple-digit =3D tstr .abnf | > 1*DIGIT "." 1*DIGIT "." 1*DIGIT > | >=20 > The ABNF could be loosely defined; as in: >=20 > opague-abnf =3D *( text / NOT-PIPE ) > NOT-PIPE =3D CRLF / %x20-5B / %x7D-10FFFD >=20 > It's more verbose. And it's unconventional. But... >=20 > Pete. > --=20 > --------------------------------------------------------------------- > Pete Cordell > http://json-content-rules.org Rule > --------------------------------------------------------------------- >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Tue Jul 17 14:11:01 2018 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 73D41130DE2 for ; Tue, 17 Jul 2018 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 T4FwnM-LoNzJ for ; Tue, 17 Jul 2018 14:10:56 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430DB129C6B for ; Tue, 17 Jul 2018 14:10:56 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 850C027548; Tue, 17 Jul 2018 17:10:54 -0400 (EDT) From: Sean Leonard Message-Id: <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F44EE13F-6573-4336-A115-5366D68A13A6" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Jul 2018 17:10:53 -0400 In-Reply-To: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> Cc: Carsten Bormann , cbor@ietf.org To: Island Resort References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 21:11:00 -0000 --Apple-Mail=_F44EE13F-6573-4336-A115-5366D68A13A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 14, 2018, at 1:37 PM, Island Resort = wrote: >=20 > To go on a bit further just on canonicalization, there are (only?) = four ways encoding can vary: > 1) integers =E2=80=94 used either as a value or a length > 2) indefinite vs definite lengths =E2=80=94 for strings, maps and = arrays > 3) map =E2=80=94 sorting order > 4) float =E2=80=94 encoding of NaN and infinity >=20 > Since there are only four, maybe we specify the canonical encoding for = each individually and precisely. A protocol can choose which they want = =C3=A0 la carte if they need to. Full canonical encoding would still be = preferred and a SHOULD. There are many other ways that encoding can vary, when tagged data items = come into play. Consider a small positive integer that can be encoded as a big number: = it could be an integer (major type 0) or a byte string with tag 2 = (bignum). The byte string for 1 could be h'01', h'0001, h'000001', etc. = The application may consider the length of the byte string to be an = important signal, e.g., of precision. Naturally, such a number could also be represented as a bigfloat (type = 5). Conversely=E2=80=A6if an implementation knows how to process bignums, it = knows 2(h'01') is equivalent to 2(h'0001'), but untagged h'01' is not = equivalent to h'0001'. A decoder that is tag-agnostic will (likely) = treat the tagged version the same as the untagged version, which is to = say, not equivalent. The question is when you want data to be =E2=80=9Ccanonicalized=E2=80=9D, = what are the range of types that you are going to accept, and what might = your application consider to be equivalent representations=E2=80=A6which = may depend not only on the application protocol, but the implementing = platform. Python has no hard limit or range to ints; therefore, the = single most natural way to represent integers in CBOR with a Python = implementation would be bignums (although, for most real world cases, = this would not be very efficient). >=20 > Each canonical encoding would be described tightly with MUSTs = conditional on whether it is providing canonical encoding support. For = example, =E2=80=9CIF canonical float encoding is implemented, NaN MUST = be expressed as 0xf97e00=E2=80=9D. The current language for float is = =E2=80=9Cmight need to=E2=80=A6=E2=80=9D. Making canonicalization conditional will quickly lead to 2^(tags+4) = possible implementation variations, where tags is the number of = allocated tags in the IANA registry. :( Sean >=20 >=20 > I=E2=80=99m here in Montreal and will be at the CBOR meeting. But = maybe you didn=E2=80=99t want to hear that. :-) >=20 > LL >=20 >=20 >=20 >=20 >> On Jul 13, 2018, at 6:01 PM, Carsten Bormann > wrote: >>=20 >> There is a discussion going on in the thread about Tag 1 that I'm not >> sure I understand. Since representation variants seem to play a big >> role in that discussion, I thought I should write up some background >> on representation variants in CBOR. >>=20 >> (Paragraphs in parentheses are additional background information that >> can be skipped.) >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> # Representation Variants in CBOR >>=20 >> In CBOR, there is often more than one way to serialize a data model >> item. >>=20 >> For instance, the unsigned integer value 1 can be represented as = 0x01, >> 0x1801, 0x190001, 0x2000000001, 0x210000000000000001. >>=20 >> (There are other approaches to this problem. For example, according >> to the encoding principles underlying UTF-8, the string "1" could be >> represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. UTF-8 = [RFC3629] >> simply outlaws the longer representation variants, so there never is = a >> choice. Another approach is to make the encoding non-redundant, as >> for instance with the CoAP option length [RFC7252]: The single-nibble >> encoding spans the values 0 to 12, the 1.5-byte encoding spans 13 to >> 268, and the 2.5-byte encoding spans 269 to 65804. As with the UTF-8 >> encoding rules, there is never a choice, but here there isn't even a >> need for code to check for outlawed values.) >>=20 >> Consistent encoding (called canonicalization in RFC 7049) aims at a >> single defined serialization of a data model item. >>=20 >> However, there is a cost to consistent encoding (in particular when >> maps are involved), so the basic mode of using CBOR does not employ >> consistent encoding. >>=20 >> CBOR has been defined to enable very simple implementations for >> applications in very constrained environments. So it is relatively >> modest in its hard and fast requirements. However, there is an >> expectation that an implementation not targeted at very constrained >> environments (which we will call a full-function implementation here) >> at least: >>=20 >> - accepts all representation variants (unless specifically told not >> to, e.g. when checking consistent encoding), and >> - only emits the shortest of multiple alternative representation >> variants for each data item. >>=20 >> Today's implementations pretty much universally fulfill this >> expectation for integers, string lengths, container counts, and tags, >> but some do fall short for floating point values. >>=20 >> (Even otherwise proficient programmers are often scared of floating >> point, or they may just not care about floating point values, or = both. >> There is example code in the RFC, as well as in many of the 50+ CBOR >> implementations available as open source, so there is little excuse >> for chickening out on fully implementing floating point. Some >> implementation languages do make it harder than necessary to operate >> on floating point values, though -- implementers for those languages >> have this writer's sympathy.) >>=20 >> A full-function implementation can decode any representation variant >> that a constrained implementation might generate. In the inverse >> direction, there may be some limitations on the constrained side that >> a CBOR-based protocol may want to make explicit: E.g., it could >> restrict integer values to 32-bit ranges (int32 OR uint32) or even 16 >> bits where that is possible. It could also do without 64-bit = floating >> point where constrained implementations might be limited to 32-bit >> floating point libraries. >>=20 >> (This is probably where the discussion of Tag 1 currently going on in >> the mailing list was touching representation variants first: 32-bit >> floating point is not generally very useful for 1970-epoch based >> times, but a full-function implementation sending a floating-point >> epoch-based time will generate a 32-bit representation if the time >> happens to fall on an integer multiple of currently 128 seconds.) >>=20 >> At the data model level (where tags are defined, and where CDDL >> operates), such limitations only limit the range of values; a >> full-function generic encoder will then only generate the >> representation variants intended. A constrained encoder = theoretically >> could be oblivious of this intent and, e.g., generate a 64-bit = integer >> representation; most likely, these implementations are highly >> integrated between data model and serialization layers and thus will >> already do the right thing. >>=20 >> (Theoretically, a constrained CBOR implementation could be written to >> only ever accept a specific representation variant that is not the >> shortest -- e.g. 0x190001 for the example above. This would limit >> interoperability considerably and therefore probably isn't a smart >> move.) >>=20 >> CDDL does not have any language features to restrict representation >> variants, as it operates at the data model level. It does allow >> restricting the range of a value such that a full-function encoder >> would only use a certain subset of representation variants (e.g., >> float32 might be represented in 16-bit or 32-bit serialization, but >> never needs 64-bit serialization). However, there is no way to force >> a representation variant that is longer than the shortest one >> possible, and it is NOT RECOMMENDED to define CBOR protocols that >> would require doing so. >>=20 >> (Yes, this also applies to floating point. While a high-speed = encoder >> on a fast network might want to forego the couple of instructions >> needed for selection of the shortest encoding, the decoder should >> always be able to handle the shorter cases as well.) >>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_F44EE13F-6573-4336-A115-5366D68A13A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 14, 2018, at 1:37 PM, Island Resort <lgl@island-resort.com> wrote:

To go = on a bit further just on canonicalization, there are (only?) four = ways encoding can vary:
1) = integers =E2=80=94 used either as a value or a length
2) indefinite vs definite lengths =E2=80=94 for strings, maps = and arrays
3) map =E2=80=94 sorting order
4) float =E2=80=94 encoding of NaN and = infinity

Since there are only four, maybe we specify the canonical = encoding for each individually and precisely. A protocol can choose = which they want =C3=A0 la carte if they need to. Full canonical encoding = would still be preferred and a = SHOULD.

There= are many other ways that encoding can vary, when tagged data items come = into play.

Consider a small positive = integer that can be encoded as a big number: it could be an integer = (major type 0) or a byte string with tag 2 (bignum). The byte string for = 1 could be h'01', h'0001, h'000001', etc. The application may consider = the length of the byte string to be an important signal, e.g., of = precision.

Naturally, such a number = could also be represented as a bigfloat (type 5).

Conversely=E2=80=A6if an implementation knows how = to process bignums, it knows 2(h'01') is equivalent to 2(h'0001'), but = untagged h'01' is not equivalent to h'0001'. A decoder that is = tag-agnostic will (likely) treat the tagged version the same as the = untagged version, which is to say, not equivalent.

The question is when you want data to be = =E2=80=9Ccanonicalized=E2=80=9D, what are the range of types that you = are going to accept, and what might your application consider to be = equivalent representations=E2=80=A6which may depend not only on the = application protocol, but the implementing platform. Python has no hard = limit or range to ints; therefore, the single most natural way to = represent integers in CBOR with a Python implementation would be bignums = (although, for most real world cases, this would not be very = efficient).


Each canonical encoding = would be described tightly with MUSTs conditional on whether it is = providing canonical encoding support. For example, =E2=80=9CIF canonical = float encoding is implemented, NaN MUST be expressed = as 0xf97e00=E2=80=9D. The current language for float is =E2=80=9Cmigh= t need to=E2=80=A6=E2=80=9D.

Making canonicalization conditional will quickly = lead to 2^(tags+4) possible implementation variations, = where tags is the number of allocated tags in the IANA = registry. :(

Sean



I=E2=80=99m here in = Montreal and will be at the CBOR meeting. But maybe you didn=E2=80=99t = want to hear that. :-)

LL




On Jul = 13, 2018, at 6:01 PM, Carsten Bormann <cabo@tzi.org> wrote:

There = is a discussion going on in the thread about Tag 1 that I'm not
sure I understand.  Since representation variants seem = to play a big
role in that discussion, I thought I should = write up some background
on representation variants in = CBOR.

(Paragraphs in parentheses are = additional background information that
can be skipped.)

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


# Representation Variants in CBOR

In CBOR, there is often more than one way to = serialize a data model
item.

For instance, the unsigned integer value 1 can be represented = as 0x01,
0x1801, 0x190001, 0x2000000001, = 0x210000000000000001.

(There are other = approaches to this problem.  For example, according
to = the encoding principles underlying UTF-8, the string "1" could be
represented as 0x31, 0xC0B1, 0xE080B1, or 0xF08080B1. =  UTF-8 [RFC3629]
simply outlaws the longer = representation variants, so there never is a
choice. =  Another approach is to make the encoding non-redundant, as
for instance with the CoAP option length [RFC7252]: The = single-nibble
encoding spans the values 0 to 12, the = 1.5-byte encoding spans 13 to
268, and the 2.5-byte = encoding spans 269 to 65804.  As with the UTF-8
encoding rules, there is never a choice, but here there isn't = even a
need for code to check for outlawed values.)

Consistent encoding (called canonicalization = in RFC 7049) aims at a
single defined serialization of a = data model item.

However, there is a cost = to consistent encoding (in particular when
maps are = involved), so the basic mode of using CBOR does not employ
consistent encoding.

CBOR has = been defined to enable very simple implementations for
applications in very constrained environments.  So it is = relatively
modest in its hard and fast requirements. =  However, there is an
expectation that an = implementation not targeted at very constrained
environments= (which we will call a full-function implementation here)
at= least:

- accepts all representation = variants (unless specifically told not
 to, e.g. = when checking consistent encoding), and
- only emits the = shortest of multiple alternative representation
=  variants for each data item.

Today's = implementations pretty much universally fulfill this
expectation for integers, string lengths, container counts, = and tags,
but some do fall short for floating point = values.

(Even otherwise proficient = programmers are often scared of floating
point, or they = may just not care about floating point values, or both.
There is example code in the RFC, as well as in many of the = 50+ CBOR
implementations available as open source, so = there is little excuse
for chickening out on fully = implementing floating point.  Some
implementation = languages do make it harder than necessary to operate
on = floating point values, though -- implementers for those languages
have this writer's sympathy.)

A = full-function implementation can decode any representation variant
that a constrained implementation might generate.  In = the inverse
direction, there may be some limitations on = the constrained side that
a CBOR-based protocol may want = to make explicit: E.g., it could
restrict integer values = to 32-bit ranges (int32 OR uint32) or even 16
bits where = that is possible.  It could also do without 64-bit floating
point where constrained implementations might be limited to = 32-bit
floating point libraries.

(This is probably where the discussion of Tag 1 currently = going on in
the mailing list was touching representation = variants first: 32-bit
floating point is not generally = very useful for 1970-epoch based
times, but a = full-function implementation sending a floating-point
epoch-based time will generate a 32-bit representation if the = time
happens to fall on an integer multiple of currently = 128 seconds.)

At the data model level = (where tags are defined, and where CDDL
operates), such = limitations only limit the range of values; a
full-function = generic encoder will then only generate the
representation = variants intended.  A constrained encoder theoretically
could be oblivious of this intent and, e.g., generate a = 64-bit integer
representation; most likely, these = implementations are highly
integrated between data model = and serialization layers and thus will
already do the = right thing.

(Theoretically, a constrained = CBOR implementation could be written to
only ever accept a = specific representation variant that is not the
shortest = -- e.g. 0x190001 for the example above.  This would limit
interoperability considerably and therefore probably isn't a = smart
move.)

CDDL does not = have any language features to restrict representation
variants, as it operates at the data model level.  It = does allow
restricting the range of a value such that a = full-function encoder
would only use a certain subset of = representation variants (e.g.,
float32 might be = represented in 16-bit or 32-bit serialization, but
never = needs 64-bit serialization).  However, there is no way to force
a representation variant that is longer than the shortest = one
possible, and it is NOT RECOMMENDED to define CBOR = protocols that
would require doing so.

(Yes, this also applies to floating point.  While a = high-speed encoder
on a fast network might want to forego = the couple of instructions
needed for selection of the = shortest encoding, the decoder should
always be able to = handle the shorter cases as well.)


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

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

= --Apple-Mail=_F44EE13F-6573-4336-A115-5366D68A13A6-- From nobody Tue Jul 17 15:03:18 2018 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 C876E130EB3 for ; Tue, 17 Jul 2018 15:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6J5NtnKkMZy for ; Tue, 17 Jul 2018 15:02:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA01130E77 for ; Tue, 17 Jul 2018 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6HM2m18024312; Wed, 18 Jul 2018 00:02:48 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:4885:f187:a964:83ad] (unknown [IPv6:2001:67c:1232:144:4885:f187:a964:83ad]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41VZ5h0d25zDXlD; Wed, 18 Jul 2018 00:02:47 +0200 (CEST) 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: <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> Date: Tue, 17 Jul 2018 18:02:46 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 553557764.756713-0f6f20203ed35ac17114d2519bddad62 Content-Transfer-Encoding: quoted-printable Message-Id: <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:02:55 -0000 On Jul 17, 2018, at 17:10, Sean Leonard wrote: >=20 >=20 >=20 >> On Jul 14, 2018, at 1:37 PM, Island Resort = wrote: >>=20 >> To go on a bit further just on canonicalization, there are (only?) = four ways encoding can vary: >> 1) integers =E2=80=94 used either as a value or a length >> 2) indefinite vs definite lengths =E2=80=94 for strings, maps and = arrays >> 3) map =E2=80=94 sorting order >> 4) float =E2=80=94 encoding of NaN and infinity >>=20 >> Since there are only four, maybe we specify the canonical encoding = for each individually and precisely. A protocol can choose which they = want =C3=A0 la carte if they need to. Full canonical encoding would = still be preferred and a SHOULD. >=20 > There are many other ways that encoding can vary, when tagged data = items come into play. >=20 > Consider a small positive integer that can be encoded as a big number: Don=E2=80=99t do that, that=E2=80=99s not =E2=80=9Cpreferred = serialization=E2=80=9D. > it could be an integer (major type 0) or a byte string with tag 2 = (bignum). The byte string for 1 could be h'01', h'0001, h'000001', etc. = The application may consider the length of the byte string to be an = important signal, e.g., of precision. >=20 > Naturally, such a number could also be represented as a bigfloat (type = 5). Again, don=E2=80=99t do that, use plain float. > Conversely=E2=80=A6if an implementation knows how to process bignums, = it knows 2(h'01') is equivalent to 2(h'0001'), but untagged h'01' is not = equivalent to h'0001'. A decoder that is tag-agnostic will (likely) = treat the tagged version the same as the untagged version, which is to = say, not equivalent. That is something that the consistent encoding spec for an application = would need to define. So the spec should probably say that preferred encoding for bignums does = not have leading zeros. (Right now, it just says Decoders that understand these tags MUST be able to decode bignums that have leading zeroes. Which implies, but does not spell out, that leading zeroes are a bit = weird.) > The question is when you want data to be =E2=80=9Ccanonicalized=E2=80=9D= , what are the range of types that you are going to accept, and what = might your application consider to be equivalent representations=E2=80=A6w= hich may depend not only on the application protocol, but the = implementing platform. Python has no hard limit or range to ints; = therefore, the single most natural way to represent integers in CBOR = with a Python implementation would be bignums (although, for most real = world cases, this would not be very efficient). The natural way is to use bignums only for numbers that don=E2=80=99t = fit in uint/nint. >> Each canonical encoding would be described tightly with MUSTs = conditional on whether it is providing canonical encoding support. For = example, =E2=80=9CIF canonical float encoding is implemented, NaN MUST = be expressed as 0xf97e00=E2=80=9D. The current language for float is = =E2=80=9Cmight need to=E2=80=A6=E2=80=9D. >=20 > Making canonicalization conditional will quickly lead to 2^(tags+4) = possible implementation variations, where tags is the number of = allocated tags in the IANA registry. :( Hence the desire to define a preferred serialization. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 17 15:31:50 2018 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 B743C130E4D for ; Tue, 17 Jul 2018 15:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 L5rcUMSm9sQ2 for ; Tue, 17 Jul 2018 15:31:45 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C68130DDC for ; Tue, 17 Jul 2018 15:31:45 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB05027505; Tue, 17 Jul 2018 18:31:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <46C63155-C2AB-4DBF-9348-3D42782A452E@tzi.org> Date: Tue, 17 Jul 2018 18:31:42 -0400 Cc: Pete Cordell , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <912F8EDD-2037-46D7-A916-865938A9EC05@seantek.com> References: <46C63155-C2AB-4DBF-9348-3D42782A452E@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:31:48 -0000 A solution to the ABNF referencing problem is discussed in Section 3 of = draft-seantek-more-core-rules-08 = . For = example: emailAddress =3D text .abnf addr-spec@[RFC5322] :) (A similar kind of reference notation could be developed for CDDL = itself, but I am not proposing such a thing at this time.) Regards, Sean > On Jul 17, 2018, at 4:54 PM, Carsten Bormann wrote: >=20 > Hi Pete, >=20 > Mixing in ABNF into CDDL is still something I=E2=80=99d like to do = (for 2.0). >=20 > A simple control like the .abnf you used in March is not enough, since = most ABNF right hand sides require one or more rules to become useful. = In this case, DIGIT (even if that happens to be a core rule =E2=80=94 = you still have to provide it). A good place to keep those additional = rules hasn=E2=80=99t occurred to me. >=20 > Also, it would be nice for this to have an equivalent of Python=E2=80=99= s =E2=80=9C=E2=80=9D=E2=80=9D for this =E2=80=94 you used | (which would = be quite confusing for people that think in classic BNF). >=20 > Ugly straw man: maybe something like >=20 > triple-digit =3D text .abnf =E2=80=9C=E2=80=9D=E2=80=9D 1*DIGIT = 2*(=E2=80=9C.=E2=80=9D 1*DIGIT) > DIGIT =3D %x30-39 > =E2=80=9C=E2=80=9D=E2=80=9D >=20 > (i.e., the first line of the string is used as the RHS for an = anonymous ABNF rule, the others provide additional rules.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Mar 30, 2018, at 08:09, Pete Cordell = wrote: >>=20 >> Thinking laterally, if specifying a regex format is problematic, is = it worth considering ABNF as an alternative? >>=20 >> The pipe character could act as a suitable delimiter. For example: >>=20 >> triple-digit =3D tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT | >>=20 >> Over multiple lines it could look like: >>=20 >> triple-digit =3D tstr .abnf | >> 1*DIGIT "." 1*DIGIT "." 1*DIGIT >> | >>=20 >> The ABNF could be loosely defined; as in: >>=20 >> opague-abnf =3D *( text / NOT-PIPE ) >> NOT-PIPE =3D CRLF / %x20-5B / %x7D-10FFFD >>=20 >> It's more verbose. And it's unconventional. But... >>=20 >> Pete. >> --=20 >> --------------------------------------------------------------------- >> Pete Cordell >> http://json-content-rules.org Rule >> --------------------------------------------------------------------- >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jul 17 15:56:01 2018 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 9622A130E2E for ; Tue, 17 Jul 2018 15:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsZ3p-xWW44U for ; Tue, 17 Jul 2018 15:55:53 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8D3130E1E for ; Tue, 17 Jul 2018 15:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6HMtmcx002781; Wed, 18 Jul 2018 00:55:48 +0200 (CEST) Received: from [IPv6:2001:67c:1232:144:4885:f187:a964:83ad] (unknown [IPv6:2001:67c:1232:144:4885:f187:a964:83ad]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41VbGq3hTdzDXlh; Wed, 18 Jul 2018 00:55:47 +0200 (CEST) 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: <912F8EDD-2037-46D7-A916-865938A9EC05@seantek.com> Date: Tue, 17 Jul 2018 18:55:45 -0400 Cc: cbor@ietf.org, Pete Cordell X-Mao-Original-Outgoing-Id: 553560944.31971-c1305ad04904cc76129d1d50fb9de017 Content-Transfer-Encoding: quoted-printable Message-Id: <9392B0BC-4D5B-48A3-80E8-8456EF60E4BF@tzi.org> References: <46C63155-C2AB-4DBF-9348-3D42782A452E@tzi.org> <912F8EDD-2037-46D7-A916-865938A9EC05@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 22:55:57 -0000 An external referencing system (preferably using URIs) would be a useful = component of the module system that has been bandied about for CDDL 2.0. = Not sure that extracting an ABNF (or CDDL) rule by name from an RFC is = always well-defined, but it will be in most useful applications of this. Gr=C3=BC=C3=9Fe, Carsten > On Jul 17, 2018, at 18:31, Sean Leonard wrote: >=20 > A solution to the ABNF referencing problem is discussed in Section 3 = of draft-seantek-more-core-rules-08 = . For = example: >=20 > emailAddress =3D text .abnf addr-spec@[RFC5322] >=20 > :) >=20 > (A similar kind of reference notation could be developed for CDDL = itself, but I am not proposing such a thing at this time.) >=20 > Regards, >=20 > Sean >=20 >> On Jul 17, 2018, at 4:54 PM, Carsten Bormann wrote: >>=20 >> Hi Pete, >>=20 >> Mixing in ABNF into CDDL is still something I=E2=80=99d like to do = (for 2.0). >>=20 >> A simple control like the .abnf you used in March is not enough, = since most ABNF right hand sides require one or more rules to become = useful. In this case, DIGIT (even if that happens to be a core rule =E2=80= =94 you still have to provide it). A good place to keep those = additional rules hasn=E2=80=99t occurred to me. >>=20 >> Also, it would be nice for this to have an equivalent of Python=E2=80=99= s =E2=80=9C=E2=80=9D=E2=80=9D for this =E2=80=94 you used | (which would = be quite confusing for people that think in classic BNF). >>=20 >> Ugly straw man: maybe something like >>=20 >> triple-digit =3D text .abnf =E2=80=9C=E2=80=9D=E2=80=9D 1*DIGIT = 2*(=E2=80=9C.=E2=80=9D 1*DIGIT) >> DIGIT =3D %x30-39 >> =E2=80=9C=E2=80=9D=E2=80=9D >>=20 >> (i.e., the first line of the string is used as the RHS for an = anonymous ABNF rule, the others provide additional rules.) >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 30, 2018, at 08:09, Pete Cordell = wrote: >>>=20 >>> Thinking laterally, if specifying a regex format is problematic, is = it worth considering ABNF as an alternative? >>>=20 >>> The pipe character could act as a suitable delimiter. For example: >>>=20 >>> triple-digit =3D tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT | >>>=20 >>> Over multiple lines it could look like: >>>=20 >>> triple-digit =3D tstr .abnf | >>> 1*DIGIT "." 1*DIGIT "." 1*DIGIT >>> | >>>=20 >>> The ABNF could be loosely defined; as in: >>>=20 >>> opague-abnf =3D *( text / NOT-PIPE ) >>> NOT-PIPE =3D CRLF / %x20-5B / %x7D-10FFFD >>>=20 >>> It's more verbose. And it's unconventional. But... >>>=20 >>> Pete. >>> --=20 >>> = --------------------------------------------------------------------- >>> Pete Cordell >>> http://json-content-rules.org Rule >>> = --------------------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Tue Jul 17 19:10:34 2018 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 5B6FE130E7B for ; Tue, 17 Jul 2018 19:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jAUf3oFkV9Xh for ; Tue, 17 Jul 2018 19:10:30 -0700 (PDT) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.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 A620F130E6E for ; Tue, 17 Jul 2018 19:10:30 -0700 (PDT) Received: from [192.168.2.61] ([76.69.234.166]) by :SMTPAUTH: with ESMTPSA id fbvBfeHuV669vfbvBf0npw; Tue, 17 Jul 2018 19:10:30 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9EFA0846-8DDE-4593-BDB5-CA0A0731738A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Jul 2018 22:10:28 -0400 In-Reply-To: <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> Cc: Sean Leonard , cbor@ietf.org To: Carsten Bormann References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfHfxVzhpepJoWbH2cNbWawN7oydm6KiMtpUVqNDI8pNB07netZgGi5p4W3B4+rLFwIpodkydo1qWEh/JjRVlwRGRzNzyf2CcUEEGG/2e3bfLoB7CmL4Y bGtyN1QV2nNWSnz1IBubNl5euF16OouZ9gr0ZEiFOsT8mw/wLiYMpfIJoToQRObPvhsH8ToQLMWXVnvTkbPYR3Ysy32jPESbDCEl8swTQPMe1fCq7T+LxDL5 Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 02:10:33 -0000 --Apple-Mail=_9EFA0846-8DDE-4593-BDB5-CA0A0731738A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I like preferred serialization. For me at least, it is getting clear = what is a type and what is serialization. Anything to do with type is = not serialization and we manage interop of that in the description of = the types used by the protocol.=20 These are all the preferred serializations, right? Major type 0 and 1 =E2=80=94 encode integers as short as possible Major type 2 and 3 =E2=80=94 encode the length of the string as short as = possible; do not use indefinite lengths. Major type 4 =E2=80=94 encode the length of the array as short as = possible; do not use the indefinite length. Major type 5 =E2=80=94 same as major type 5; in addition sort by keys I like stating them by major type so a design like by dumb sensor + = smart server can say: - The dumb sensor doesn=E2=80=99t have to use any preferred = serializations for data it sends - The smart server must use the preferred serialization for major = type 2 and 3 As Carsten is saying, the variation for things like expression of time = or a URL is not a serialization variant because you can be explicit = about in the CDDL, in the data model. I would expect implementations that translate data formats to python, = JSON or such would always use all preferred serializations because they = really aren=E2=80=99t constrained. Also sending preferred serialization = to a constrained device is almost always best so this works out well = even when talking to a constrained device with a python implementation. LL > On Jul 17, 2018, at 6:02 PM, Carsten Bormann wrote: >=20 > On Jul 17, 2018, at 17:10, Sean Leonard wrote: >>=20 >>=20 >>=20 >>> On Jul 14, 2018, at 1:37 PM, Island Resort = wrote: >>>=20 >>> To go on a bit further just on canonicalization, there are (only?) = four ways encoding can vary: >>> 1) integers =E2=80=94 used either as a value or a length >>> 2) indefinite vs definite lengths =E2=80=94 for strings, maps and = arrays >>> 3) map =E2=80=94 sorting order >>> 4) float =E2=80=94 encoding of NaN and infinity >>>=20 >>> Since there are only four, maybe we specify the canonical encoding = for each individually and precisely. A protocol can choose which they = want =C3=A0 la carte if they need to. Full canonical encoding would = still be preferred and a SHOULD. >>=20 >> There are many other ways that encoding can vary, when tagged data = items come into play. >>=20 >> Consider a small positive integer that can be encoded as a big = number: >=20 > Don=E2=80=99t do that, that=E2=80=99s not =E2=80=9Cpreferred = serialization=E2=80=9D. >=20 >> it could be an integer (major type 0) or a byte string with tag 2 = (bignum). The byte string for 1 could be h'01', h'0001, h'000001', etc. = The application may consider the length of the byte string to be an = important signal, e.g., of precision. >>=20 >> Naturally, such a number could also be represented as a bigfloat = (type 5). >=20 > Again, don=E2=80=99t do that, use plain float. >=20 >> Conversely=E2=80=A6if an implementation knows how to process bignums, = it knows 2(h'01') is equivalent to 2(h'0001'), but untagged h'01' is not = equivalent to h'0001'. A decoder that is tag-agnostic will (likely) = treat the tagged version the same as the untagged version, which is to = say, not equivalent. >=20 > That is something that the consistent encoding spec for an application = would need to define. > So the spec should probably say that preferred encoding for bignums = does not have leading zeros. >=20 > (Right now, it just says >=20 > Decoders > that understand these tags MUST be able to decode bignums that have > leading zeroes. >=20 > Which implies, but does not spell out, that leading zeroes are a bit = weird.) >=20 >> The question is when you want data to be =E2=80=9Ccanonicalized=E2=80=9D= , what are the range of types that you are going to accept, and what = might your application consider to be equivalent representations=E2=80=A6w= hich may depend not only on the application protocol, but the = implementing platform. Python has no hard limit or range to ints; = therefore, the single most natural way to represent integers in CBOR = with a Python implementation would be bignums (although, for most real = world cases, this would not be very efficient). >=20 > The natural way is to use bignums only for numbers that don=E2=80=99t = fit in uint/nint. >=20 >>> Each canonical encoding would be described tightly with MUSTs = conditional on whether it is providing canonical encoding support. For = example, =E2=80=9CIF canonical float encoding is implemented, NaN MUST = be expressed as 0xf97e00=E2=80=9D. The current language for float is = =E2=80=9Cmight need to=E2=80=A6=E2=80=9D. >>=20 >> Making canonicalization conditional will quickly lead to 2^(tags+4) = possible implementation variations, where tags is the number of = allocated tags in the IANA registry. :( >=20 > Hence the desire to define a preferred serialization. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_9EFA0846-8DDE-4593-BDB5-CA0A0731738A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = like preferred serialization. For me at least, it is = getting clear what is a type and what is serialization. Anything to do = with type is not serialization and we manage interop of that in the = description of the types used by the protocol. 

These are all the preferred = serializations, right?

Major type 0 and 1 =E2=80=94 = encode integers as short as possible

Major type 2 and 3 =E2=80=94 encode the = length of the string as short as possible; do not use indefinite = lengths.

Major = type 4 =E2=80=94 encode the length of the array as short as possible; do = not use the indefinite length.

Major type 5 =E2=80=94 same as major = type 5; in addition sort by keys

I like stating them by = major type so a design like by dumb sensor + smart server can = say:
   - The dumb sensor doesn=E2=80=99t = have to use any preferred serializations for data it = sends
   - The smart server must use the = preferred serialization for major type 2 and 3

As Carsten is saying, the variation for = things like expression of time or a URL is not a serialization variant = because you can be explicit about in the CDDL, in the data = model.

I would = expect implementations that translate data formats to python, JSON or = such would always use all preferred serializations because they really = aren=E2=80=99t constrained. Also sending preferred serialization to a = constrained device is almost always best so this works out well even = when talking to a constrained device with a python = implementation.

LL



On Jul = 17, 2018, at 6:02 PM, Carsten Bormann <cabo@tzi.org> wrote:

On = Jul 17, 2018, at 17:10, Sean Leonard <dev+ietf@seantek.com> wrote:



On Jul 14, 2018, at 1:37 = PM, Island Resort <lgl@island-resort.com> wrote:

To go on a bit further just on canonicalization, there are = (only?) four ways encoding can vary:
1) integers =E2=80=94 = used either as a value or a length
2) indefinite vs = definite lengths =E2=80=94 for strings, maps and arrays
3) = map =E2=80=94 sorting order
4) float =E2=80=94 encoding of = NaN and infinity

Since there are only four, = maybe we specify the canonical encoding for each individually and = precisely. A protocol can choose which they want =C3=A0 la carte if they = need to. Full canonical encoding would still be preferred and a = SHOULD.

There are many other = ways that encoding can vary, when tagged data items come into play.

Consider a small positive integer that can be = encoded as a big number:

Don=E2=80= =99t do that, that=E2=80=99s not =E2=80=9Cpreferred serialization=E2=80=9D= .

it = could be an integer (major type 0) or a byte string with tag 2 (bignum). = The byte string for 1 could be h'01', h'0001, h'000001', etc. The = application may consider the length of the byte string to be an = important signal, e.g., of precision.

Naturally, such a number could also be represented as a = bigfloat (type 5).

Again, = don=E2=80=99t do that, use plain float.

Conversely=E2=80=A6if an = implementation knows how to process bignums, it knows 2(h'01') is = equivalent to 2(h'0001'), but untagged h'01' is not equivalent to = h'0001'. A decoder that is tag-agnostic will (likely) treat the tagged = version the same as the untagged version, which is to say, not = equivalent.

That is something = that the consistent encoding spec for an application would need to = define.
So the spec should probably say that preferred = encoding for bignums does not have leading zeros.

(Right now, it just says

=   Decoders
  that understand these = tags MUST be able to decode bignums that have
=   leading zeroes.

Which implies, = but does not spell out, that leading zeroes are a bit weird.)

The = question is when you want data to be =E2=80=9Ccanonicalized=E2=80=9D, = what are the range of types that you are going to accept, and what might = your application consider to be equivalent representations=E2=80=A6which = may depend not only on the application protocol, but the implementing = platform. Python has no hard limit or range to ints; therefore, the = single most natural way to represent integers in CBOR with a Python = implementation would be bignums (although, for most real world cases, = this would not be very efficient).

The natural way is to use bignums only for numbers that = don=E2=80=99t fit in uint/nint.

Each = canonical encoding would be described tightly with MUSTs conditional on = whether it is providing canonical encoding support. For example, =E2=80=9C= IF canonical float encoding is implemented, NaN MUST be expressed as = 0xf97e00=E2=80=9D. The current language for float is =E2=80=9Cmight need = to=E2=80=A6=E2=80=9D.

Making = canonicalization conditional will quickly lead to 2^(tags+4) possible = implementation variations, where tags is the number of allocated tags in = the IANA registry. :(

Hence = the desire to define a preferred serialization.

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

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

= --Apple-Mail=_9EFA0846-8DDE-4593-BDB5-CA0A0731738A-- From nobody Tue Jul 17 19:26:53 2018 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 34CB3131090 for ; Tue, 17 Jul 2018 19:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd4faIof6MOr for ; Tue, 17 Jul 2018 19:26:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660B2130F39 for ; Tue, 17 Jul 2018 19:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6I2QjMC011322; Wed, 18 Jul 2018 04:26:45 +0200 (CEST) Received: from [IPv6:2001:638:708:18::c] (unknown [IPv6:2001:638:708:18::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41VgyD6WBwzDXn2; Wed, 18 Jul 2018 04:26:44 +0200 (CEST) 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: Tue, 17 Jul 2018 22:26:42 -0400 Cc: cbor@ietf.org, Sean Leonard X-Mao-Original-Outgoing-Id: 553573600.519581-4787fc7ddbda89121f3073a24b378857 Content-Transfer-Encoding: quoted-printable Message-Id: <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 02:26:51 -0000 Hi Laurence, I=E2=80=99m mostly with you here, except for: > On Jul 17, 2018, at 22:10, Laurence Lundblade = wrote: >=20 > Major type 5 =E2=80=94 same as major type 5; in addition sort by keys I don=E2=80=99t think the sorting can be part of the preferred = serialization, this would be consistent serialization only. It is just = too expensive. Major type 6 =E2=80=94 encode the tag as short as possible Major type 7 =E2=80=94 encode floating point as short as possible. So maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D = and just state it as a general rule, because it is a general rule. # If there is more than one serialization variant available that differ = in overall length, the preferred serialization uses the shortest one. Now, indefinite actually is shorter for, e.g., arrays of more than 255 = elements, so the preference for definite should be explicitly *higher = priority* than the overall length. On the other hand, the preference = for definite is *weaker* =E2=80=94 there are many good reasons to go to = indefinite length in particular for arrays and maps (otherwise we = wouldn=E2=80=99t have that variant!). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 17 19:31:24 2018 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 D1F821310B3 for ; Tue, 17 Jul 2018 19:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryFA9uIXPriP for ; Tue, 17 Jul 2018 19:31:12 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 AED891310CC for ; Tue, 17 Jul 2018 19:31:12 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 188-v6so2009897ita.5 for ; Tue, 17 Jul 2018 19:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=HdiijplFI3xuQi55dgj1DuBIWabsxGpLyAzy+MLw7WY=; b=S1p5VeIBN2P2ReC9g2JWth4lhdegll16+ik6r3woPa/H2w2v6JIuIxpThi0mA2sPsO hyp1rw6x5ozOmII1oFZDjo/3kAcHTvwIvCotBcP/WFj6uPZ5073yHxTxzZiwofh4Eui4 rIPR6ScVeD6jeQmHYMtou0MeStx6EjjSfjlPizJqeLqX1F4+b7pfMumy3S6YVaCowCZA J+tO6vU9wtWUeP0QmcMsQXOM9SqQzpLWLkqRX31lvIi9o8QHJbqNuusSHmzfUvzqIDVd 2j/sO3+THmnJtp2hINNA8tvZESclJTVuCfhalOwPCKGJ5wySqN8RNSYtm2bAK33NX8pF xv5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=HdiijplFI3xuQi55dgj1DuBIWabsxGpLyAzy+MLw7WY=; b=Fj0ndJhqttIbEn8ee2+Un3d8BsPbWEp3RUNKnaA45tqpCbaAyX1IYlfAwsLKgPZ+Nn xDyVu2JnieEbS7hhTieV7sa7me0iYE+8ZPG8UCTTJ94g7vgKbOVTCItDwDp0+EhSFDtC nO3Kk1KW8j+qkp7HW+2AkA/5Wm5QwaRTKuZgq4dVLyhpnYXfjLGe3wWt/BcJZXN1nDWK t0exQgqGXRwOsAbVCm6fkllcorfIGZFxkcE3cJibyvG5QOMSQM0Nv7/I4EidZfWH4fIQ RU3FU+hU7XXDCvm2bVi7cswWgQ0s+mhDGLliOY6DwsMSxrWdbDE/Oq5ArynbBTWOzoCr LfSA== X-Gm-Message-State: AOUpUlGs/io191wTvDubBawY7wRE19lbrh4dVgGDK27D1DV5BRJuV3VD JPmXGxnU9pWuAjJVoKb/aKZPebbsPbTvx0yBxe2gffIu X-Google-Smtp-Source: AAOMgpfu1A1JhHUJbMPtUt8Kg9x8W+hjtO5GyVk3RAKHcHwkNiNjACq1tYWi9Be5MpL+yrl3bKA1zrPiLBftPBAS8oI= X-Received: by 2002:a24:ad45:: with SMTP id a5-v6mr506922itj.0.1531881071577; Tue, 17 Jul 2018 19:31:11 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8e88:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 19:31:11 -0700 (PDT) From: Barry Leiba Date: Tue, 17 Jul 2018 22:31:11 -0400 X-Google-Sender-Auth: A10w7h-R9Sj2i1RCiWeF1bZUAsU Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] CBOR working group conference calls X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 02:31:22 -0000 As we announced at the end of the session in Montreal, the chairs would like to set up bi-weekly conference calls to make sure the working group stays on track and makes planned progress through the CDDL and CBOR-bis documents. It will be helpful to have most of the active participants on the calls, though it isn't necessary to attend the calls in order to participate in the working group: we will report notes from the calls on the mailing list, and any decisions made on the calls will be up for review and further discussion on the mailing list before they are final. I plan to ask the Secretariat to announce conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). The plan is: Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 17:00 to 18:00 Europe/Berlin 16:00 to 17:00 Europe/London 11:00 to 12:00 America/New York 08:00 to 09:00 America/Los Angeles For other zones: https://www.epochconverter.com/timezones?q=1533740400&tz=Europe%2FBerlin We hope this time will work for most people. Please let the chairs know off list if you're never able to attend conference calls at that time, and if it turns out to be enough of a problem we'll see what we can do. For the first call, at least, the Secretariat must announce the planned schedule early next week in order to meet the IESG's rules for advance notice of conference calls. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). Barry, as chair From nobody Tue Jul 17 21:23:22 2018 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 4B397130E40 for ; Tue, 17 Jul 2018 21:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yns1riWvmzAs for ; Tue, 17 Jul 2018 21:23:18 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBFA130E67 for ; Tue, 17 Jul 2018 21:23:18 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7641927540; Wed, 18 Jul 2018 00:23:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <9392B0BC-4D5B-48A3-80E8-8456EF60E4BF@tzi.org> Date: Wed, 18 Jul 2018 00:23:14 -0400 Cc: cbor@ietf.org, Pete Cordell Content-Transfer-Encoding: quoted-printable Message-Id: References: <46C63155-C2AB-4DBF-9348-3D42782A452E@tzi.org> <912F8EDD-2037-46D7-A916-865938A9EC05@seantek.com> <9392B0BC-4D5B-48A3-80E8-8456EF60E4BF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] ABNF in place of regex (Was: Re: CDDL: Solving the regexp issue) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 04:23:21 -0000 Okay. By the way, the draft also specifies <> syntax, as in: = addr-spec@ for URIs and file paths = (in ABNF). <> syntax is not particularly useful in RFC documents, but = could/is supposed to be much more useful in flat files. Regards, Sean > On Jul 17, 2018, at 6:55 PM, Carsten Bormann wrote: >=20 > An external referencing system (preferably using URIs) would be a = useful component of the module system that has been bandied about for = CDDL 2.0. Not sure that extracting an ABNF (or CDDL) rule by name from = an RFC is always well-defined, but it will be in most useful = applications of this. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Jul 17, 2018, at 18:31, Sean Leonard wrote: >>=20 >> A solution to the ABNF referencing problem is discussed in Section 3 = of draft-seantek-more-core-rules-08 = . For = example: >>=20 >> emailAddress =3D text .abnf addr-spec@[RFC5322] >>=20 >> :) >>=20 >> (A similar kind of reference notation could be developed for CDDL = itself, but I am not proposing such a thing at this time.) >>=20 >> Regards, >>=20 >> Sean >>=20 >>> On Jul 17, 2018, at 4:54 PM, Carsten Bormann wrote: >>>=20 >>> Hi Pete, >>>=20 >>> Mixing in ABNF into CDDL is still something I=E2=80=99d like to do = (for 2.0). >>>=20 >>> A simple control like the .abnf you used in March is not enough, = since most ABNF right hand sides require one or more rules to become = useful. In this case, DIGIT (even if that happens to be a core rule =E2=80= =94 you still have to provide it). A good place to keep those = additional rules hasn=E2=80=99t occurred to me. >>>=20 >>> Also, it would be nice for this to have an equivalent of Python=E2=80=99= s =E2=80=9C=E2=80=9D=E2=80=9D for this =E2=80=94 you used | (which would = be quite confusing for people that think in classic BNF). >>>=20 >>> Ugly straw man: maybe something like >>>=20 >>> triple-digit =3D text .abnf =E2=80=9C=E2=80=9D=E2=80=9D 1*DIGIT = 2*(=E2=80=9C.=E2=80=9D 1*DIGIT) >>> DIGIT =3D %x30-39 >>> =E2=80=9C=E2=80=9D=E2=80=9D >>>=20 >>> (i.e., the first line of the string is used as the RHS for an = anonymous ABNF rule, the others provide additional rules.) >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>> On Mar 30, 2018, at 08:09, Pete Cordell = wrote: >>>>=20 >>>> Thinking laterally, if specifying a regex format is problematic, is = it worth considering ABNF as an alternative? >>>>=20 >>>> The pipe character could act as a suitable delimiter. For example: >>>>=20 >>>> triple-digit =3D tstr .abnf | 1*DIGIT "." 1*DIGIT "." 1*DIGIT | >>>>=20 >>>> Over multiple lines it could look like: >>>>=20 >>>> triple-digit =3D tstr .abnf | >>>> 1*DIGIT "." 1*DIGIT "." 1*DIGIT >>>> | >>>>=20 >>>> The ABNF could be loosely defined; as in: >>>>=20 >>>> opague-abnf =3D *( text / NOT-PIPE ) >>>> NOT-PIPE =3D CRLF / %x20-5B / %x7D-10FFFD >>>>=20 >>>> It's more verbose. And it's unconventional. But... >>>>=20 >>>> Pete. >>>> --=20 >>>> = --------------------------------------------------------------------- >>>> Pete Cordell >>>> http://json-content-rules.org Rule >>>> = --------------------------------------------------------------------- >>>>=20 >>>> _______________________________________________ >>>> CBOR mailing list >>>> CBOR@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cbor >>>>=20 >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >>=20 >=20 From nobody Tue Jul 17 22:05:38 2018 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 38079130E8D for ; Tue, 17 Jul 2018 22:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3HcqLjYWDJNB for ; Tue, 17 Jul 2018 22:05:35 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534A2130E86 for ; Tue, 17 Jul 2018 22:05:35 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D0B2E27548; Wed, 18 Jul 2018 01:05:33 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> Date: Wed, 18 Jul 2018 01:05:32 -0400 Cc: Laurence Lundblade , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 05:05:37 -0000 > On Jul 17, 2018, at 10:26 PM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 > I=E2=80=99m mostly with you here, except for: >=20 >> On Jul 17, 2018, at 22:10, Laurence Lundblade = wrote: >>=20 >> Major type 5 =E2=80=94 same as major type 5; in addition sort by keys >=20 > I don=E2=80=99t think the sorting can be part of the preferred = serialization, this would be consistent serialization only. It is just = too expensive. +1. (To me, this validates that there is a canonicalization = =E2=80=9Cladder=E2=80=9D=E2=80=94the more you want to canonicalize, the = higher you have to climb up the ladder. And it does seem that this is a = ladder to the heavens since there is always =E2=80=9Cone more thing=E2=80=9D= that you just might want to canonicalize=E2=80=A6) >=20 > Major type 6 =E2=80=94 encode the tag as short as possible >=20 > Major type 7 =E2=80=94 encode floating point as short as possible. >=20 > So maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D = and just state it as a general rule, because it is a general rule. +1. I agree with this, and with covering =E2=80=9Cas short as = possible=E2=80=9D across all major types. I also think that major type 3 needs more work in its preferred = serialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D = as that term is used in the Unicode standard. The current text of = RFC7049 does not require that the UTF-8 be well-formed. Shortest = encoding is one aspect of being well-formed, but not the only aspect. >=20 > # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >=20 > Now, indefinite actually is shorter for, e.g., arrays of more than 255 = elements, so the preference for definite should be explicitly *higher = priority* than the overall length. On the other hand, the preference = for definite is *weaker* =E2=80=94 there are many good reasons to go to = indefinite length in particular for arrays and maps (otherwise we = wouldn=E2=80=99t have that variant!). I do not know if being in definite form is desirable for this = =E2=80=9Cpreferred serialization=E2=80=9D business, for reasons that = Carsten mentions. Forcing maps and arrays to be in definite form = requires that the number of items be known in advance. (This is better = than ASN.1, which requires pre-serializing all of the elements, but is = still not the best.) Indefinite form has notable advantages, including = having an encoder be able to stream out content infinitely = (think=E2=80=A6indefinite media stream, indefinite sensor stream, etc.). Sean >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Jul 18 00:30:55 2018 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 A77121310EC for ; Wed, 18 Jul 2018 00:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCW5e3AoC6aP for ; Wed, 18 Jul 2018 00:30:50 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524701310E4 for ; Wed, 18 Jul 2018 00:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6I7UkiX000721; Wed, 18 Jul 2018 09:30:46 +0200 (CEST) Received: from [IPv6:2001:638:708:18::b] (unknown [IPv6:2001:638:708:18::b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Vpj14Dg4zDXpP; Wed, 18 Jul 2018 09:30:45 +0200 (CEST) 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, 18 Jul 2018 03:30:43 -0400 Cc: Laurence Lundblade , cbor@ietf.org X-Mao-Original-Outgoing-Id: 553591841.531262-7a974b4b715df51b2e5bf8ffa91e476f Content-Transfer-Encoding: quoted-printable Message-Id: <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 07:30:54 -0000 > On Jul 18, 2018, at 01:05, Sean Leonard wrote: >=20 >=20 >=20 >> On Jul 17, 2018, at 10:26 PM, Carsten Bormann wrote: >>=20 >> Hi Laurence, >>=20 >> I=E2=80=99m mostly with you here, except for: >>=20 >>> On Jul 17, 2018, at 22:10, Laurence Lundblade = wrote: >>>=20 >>> Major type 5 =E2=80=94 same as major type 5; in addition sort by = keys >>=20 >> I don=E2=80=99t think the sorting can be part of the preferred = serialization, this would be consistent serialization only. It is just = too expensive. >=20 > +1. (To me, this validates that there is a canonicalization = =E2=80=9Cladder=E2=80=9D=E2=80=94the more you want to canonicalize, the = higher you have to climb up the ladder. And it does seem that this is a = ladder to the heavens since there is always =E2=80=9Cone more thing=E2=80=9D= that you just might want to canonicalize=E2=80=A6) Hmm, a ladder with one step (use consistent encoding or don=E2=80=99t) = is not very laddery. Maybe more like stilts :-) >>=20 >> Major type 6 =E2=80=94 encode the tag as short as possible >>=20 >> Major type 7 =E2=80=94 encode floating point as short as possible. >>=20 >> So maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D = and just state it as a general rule, because it is a general rule. >=20 > +1. I agree with this, and with covering =E2=80=9Cas short as = possible=E2=80=9D across all major types. >=20 > I also think that major type 3 needs more work in its preferred = serialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D = as that term is used in the Unicode standard. The current text of = RFC7049 does not require that the UTF-8 be well-formed. Shortest = encoding is one aspect of being well-formed, but not the only aspect. I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. CBOR does not require any specific form (e.g. normalization form) of the = UTF-8 strings, but they do have to be UTF-8 strings. Consistent encoding requirements of an application may go beyond those = of just the CBOR serialization and may include requirements on the data = in the data items. E.g., a case-insensitive application may need to = convert strings to lower-case. Or a Unicode application may need to = normalize (in NFC, one might hope). Neither is the business of CBOR, = which is just carrying the text strings. And constrained nodes usually = can=E2=80=99t really solve the LETTER BEH WITH HAMZA ABOVE issue anyway. >> # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >>=20 >> Now, indefinite actually is shorter for, e.g., arrays of more than = 255 elements, so the preference for definite should be explicitly = *higher priority* than the overall length. On the other hand, the = preference for definite is *weaker* =E2=80=94 there are many good = reasons to go to indefinite length in particular for arrays and maps = (otherwise we wouldn=E2=80=99t have that variant!). >=20 > I do not know if being in definite form is desirable for this = =E2=80=9Cpreferred serialization=E2=80=9D business, for reasons that = Carsten mentions. Forcing maps and arrays to be in definite form = requires that the number of items be known in advance. (This is better = than ASN.1, which requires pre-serializing all of the elements, but is = still not the best.) Indefinite form has notable advantages, including = having an encoder be able to stream out content infinitely = (think=E2=80=A6indefinite media stream, indefinite sensor stream, etc.). I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. But in = many cases array and map sizes are known, and in that case (i.e., = absence of a good reason to go non-preferred) definite is still = preferred. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 18 06:17:54 2018 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 90106131204 for ; Wed, 18 Jul 2018 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c9vD0J1B24i0 for ; Wed, 18 Jul 2018 06:17:37 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13C4131208 for ; Wed, 18 Jul 2018 06:17:36 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F5B327505; Wed, 18 Jul 2018 09:17:34 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> Date: Wed, 18 Jul 2018 09:17:32 -0400 Cc: Laurence Lundblade , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 13:17:50 -0000 > On Jul 18, 2018, at 3:30 AM, Carsten Bormann wrote: >=20 >=20 >=20 >> On Jul 18, 2018, at 01:05, Sean Leonard wrote: >>=20 >>=20 >> I also think that major type 3 needs more work in its preferred = serialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D = as that term is used in the Unicode standard. The current text of = RFC7049 does not require that the UTF-8 be well-formed. Shortest = encoding is one aspect of being well-formed, but not the only aspect. >=20 > I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. >=20 > CBOR does not require any specific form (e.g. normalization form) of = the UTF-8 strings, but they do have to be UTF-8 strings. https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf D85: A Unicode code unit sequence that purports to be in a Unicode = encoding form is called well-formed if and only if it does follow the = specification of that Unicode encoding form. Summary of points: * Must be in shortest encoded form (no C0 5E stuff: identical criteria = as CBOR shortest encoded form, therefore not objectionable) * No =E2=80=9Cill-formed subsequences=E2=80=9D (example given in D86 is = <41 C2 C3 B1 42>: C2 is ill-formed because it needs to have a value in = the range 00-7F after it to correspond to a Unicode scalar value) * UTF-8 must only encode =E2=80=9CUnicode scalar values=E2=80=9D: this = is a little opaque but a =E2=80=9CUnicode scalar value=E2=80=9D (D76) is = any code point (0 - 1FFFFF) *except* surrogate code points. Therefore, = well-formed UTF-8 cannot contain U+D800-U+DFFF. See also WTF-8: https://simonsapin.github.io/wtf-8/ This requirement for well-formed UTF-8 is both obvious and extremely = counterintuitive (and potentially unproductive), depending on how you = look at it. It is =E2=80=9Cobvious=E2=80=9D because one expects the = shortest encoded form, and if you encode a surrogate pair (one = U+D800-U+DB00, followed by one U+DC00-U+DFFF), you get 6 bytes of UTF-8 = to represent a Unicode scalar value in the range U+10000-U+1FFFFF, = instead of 4 bytes of UTF-8 where the first byte starts with F0-F4. = (Also: F5-FF can never appear in UTF-8. It would have been an = interesting and perfectly valid design choice to use FF as a terminal = marker for an indefinite-length UTF-8 string in CBOR.) But it is counterintuitive and unproductive, because many software = stacks encode Unicode strings in UTF-16 but permit unpaired surrogates, = effectively treating =E2=80=9CUnicode=E2=80=9D strings as arbitrary = sequences of 16-bits. These products include JavaScript generally, = Windows, Java, Mozilla (somewhat, depends on the boundary interface), = etc. See Section 8.2 of RFC 7159. It could be a security issue to let such exceptional subsequences to go = through, but probably the worst that will happen in practice is that = emoji get snuck through an emoji scrubber. =F0=9F=98=82 The bigger point I guess is that to the extent that CBOR is a strict = superset of JSON, JSON does not formally prohibit unpaired surrogates. = (It prohibits unpaired surrogates, arguably, by requiring the JSON = source text to be in UTF-8, UTF-16, or UTF-32, but it explicitly enables = unpaired surrogates in escaped form, see Section 8.2 of RFC 7159.) In = fact, to the extent that JSON is used as the serialization format = between two implementations that both use 16-bit =E2=80=9CUTF-16=E2=80=9D = without enforcing surrogate pairing, support for unpaired surrogates in = JSON is probably necessary for interoperability. One such reason is = because if a naive implementation splits a Unicode string right between = surrogate pairs, the implementation ought also to reassemble the string = properly which will make it good again rather than delete the = temporarily offending code points. If you really want a preferred serialization for CBOR, I do believe that = the whole UTF-8 encoding thing has to be addressed. Otherwise, you treat = UTF-8 strings exactly like byte strings, but that is not helpful to a = relying application higher up in the stack. Sean >=20 > Consistent encoding requirements of an application may go beyond those = of just the CBOR serialization and may include requirements on the data = in the data items. E.g., a case-insensitive application may need to = convert strings to lower-case. Or a Unicode application may need to = normalize (in NFC, one might hope). Neither is the business of CBOR, = which is just carrying the text strings. And constrained nodes usually = can=E2=80=99t really solve the LETTER BEH WITH HAMZA ABOVE issue anyway. >=20 >>> # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >>>=20 >>> Now, indefinite actually is shorter for, e.g., arrays of more than = 255 elements, so the preference for definite should be explicitly = *higher priority* than the overall length. On the other hand, the = preference for definite is *weaker* =E2=80=94 there are many good = reasons to go to indefinite length in particular for arrays and maps = (otherwise we wouldn=E2=80=99t have that variant!). >>=20 >> I do not know if being in definite form is desirable for this = =E2=80=9Cpreferred serialization=E2=80=9D business, for reasons that = Carsten mentions. Forcing maps and arrays to be in definite form = requires that the number of items be known in advance. (This is better = than ASN.1, which requires pre-serializing all of the elements, but is = still not the best.) Indefinite form has notable advantages, including = having an encoder be able to stream out content infinitely = (think=E2=80=A6indefinite media stream, indefinite sensor stream, etc.). >=20 > I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. But = in many cases array and map sizes are known, and in that case (i.e., = absence of a good reason to go non-preferred) definite is still = preferred. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Jul 18 11:13:40 2018 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 BF6CA130F8D for ; Wed, 18 Jul 2018 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 av1o2o_BXP6B for ; Wed, 18 Jul 2018 11:13:28 -0700 (PDT) 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 63034130F5E for ; Wed, 18 Jul 2018 11:13:28 -0700 (PDT) Received: from [192.168.2.61] ([76.69.234.166]) by :SMTPAUTH: with ESMTPSA id fqx4frkghaR6vfqx5fPmS3; Wed, 18 Jul 2018 11:13:27 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Laurence Lundblade In-Reply-To: <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> Date: Wed, 18 Jul 2018 14:13:26 -0400 Cc: cbor@ietf.org, Sean Leonard Content-Transfer-Encoding: quoted-printable Message-Id: <71E2382E-68E6-40E7-ADB0-8CF377853952@island-resort.com> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfNCxwXnDlesAOKFWHpuOaJCbWFqLQUh8S+V+6Y/6WrOLLBoB3EEAc+bMTHj8gJ04+owBGksgnSgQBETOBRVsd1o3uebFnpkBCQ2+4SGNgPSMD/cT6NZ6 AtHdkUhm41ZMNJPxWN/4jeXirQsx01Lg0kfYX9GsgQIPX+QTC0Et0I8EmvGyxi18PjTiE+guNUz+o2/csdRNvDivqWgiJUD/UrPx+JOXR3Y2owif4BnCTapJ Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:13:36 -0000 I am contemplating writing a PR=E2=80=A6 Would a new sub section called =E2=80=9CPreferred Encoding=E2=80=9D be = part of "Specification for CBOR Encoding=E2=80=9D, rather than "Creating = CBOR-Based Protocols=E2=80=9D? I=E2=80=99m leaning towards the former = since it not about creating a specific protocol. Feel dumb that I forgot to say tags should be as short as possible. For the shortest float preference, we could use the steps described in = the 7049 canonicalization text. That is definitely some work for = implementors and may not be commonly implemented. I=E2=80=99ve checked a = few and not found an implementation.=20 What about not requiring shortest representation for floats? It would = make the preferred encoding for floats not the smallest and not = consistent across implementations (not canonical), but might give better = interop and might be implemented more commonly. I think we will need some description for preferred decoders too: * must decode indefinite and definite lengths * must decode integers and lengths encoded as 64-bits, 32-bits, 16-bits = and 8-bits (even on an 8-bit machine) * must decode all types of float including half-precision (when I was in = Qualcomm using half-precision code in the RFC required talking to a = lawyer; writing my own would have been hard). LL > On Jul 17, 2018, at 10:26 PM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 > I=E2=80=99m mostly with you here, except for: >=20 >> On Jul 17, 2018, at 22:10, Laurence Lundblade = wrote: >>=20 >> Major type 5 =E2=80=94 same as major type 5; in addition sort by keys >=20 > I don=E2=80=99t think the sorting can be part of the preferred = serialization, this would be consistent serialization only. It is just = too expensive. >=20 > Major type 6 =E2=80=94 encode the tag as short as possible >=20 > Major type 7 =E2=80=94 encode floating point as short as possible. >=20 > So maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D = and just state it as a general rule, because it is a general rule. >=20 > # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >=20 > Now, indefinite actually is shorter for, e.g., arrays of more than 255 = elements, so the preference for definite should be explicitly *higher = priority* than the overall length. On the other hand, the preference = for definite is *weaker* =E2=80=94 there are many good reasons to go to = indefinite length in particular for arrays and maps (otherwise we = wouldn=E2=80=99t have that variant!). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jul 18 11:58:06 2018 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 62918130FEA for ; Wed, 18 Jul 2018 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7W6CBG9AJxN for ; Wed, 18 Jul 2018 11:57:51 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25F0131053 for ; Wed, 18 Jul 2018 11:57:51 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id l25-v6so4963392ioh.12 for ; Wed, 18 Jul 2018 11:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sieNitnan+TUpx9V4kvR+x1For1uuqvE89xYsUs7xp8=; b=jKfp9AFIJQjo00QOL0RalI2DEdPoDq2eebCuHbDXLD5br4oAlxeDhWIPgIUHgPZ21q n1+I8ZV2Ik/oyovTCZlm1y/9kwV4tpjcsQ89c31j8FSYYjSlQcq3IeYT5XPNQUmKllIc zKHbb4D+EdJYRJOq7KDuZV+wLYQPQ+djxqxKMjvxSNGmjLPkHp71CdXBZ82P4scw+SiE cyyw7+TsBRg2gplyq7Taj8yqvaydRn6DVu1B8wVThSUi0gtsMkUr7b30800oGJCrgng2 9h4mBqJ6lE9FwZI3C0MZ98PiWbUEJUp8x+SRC+Lm4bGnpbCSvpDFS0c1RKc5QrlGEZFo qYfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sieNitnan+TUpx9V4kvR+x1For1uuqvE89xYsUs7xp8=; b=o5jMmdUk+9dwkOw40bcucQ6niq7iQdYL6t8iU2D34igt/OV6PXw4H5CbVvW9f+fUob z0F5y8gOquijr2/nW502xO1OF6ptRO/oaHb4lq5BQTCd1cNEJ8z+wMnzvt+BvHjc9u33 D9Ck0TSmIZph7sVzLO37Ln3B/7ooxhqbx0i5AZleSbUxBeVDqqhdVjM2Fqjrph61J4/m IIgLT5kxeR6wNI3IZL4OQ5Tdcet0jTWCGEl6gtHhxq7ATVPZotbAXJdSTBma7ENGQc0J kNVrq/qZkIpbtqYTBn7qP2Hm0fTJR8vARUTsmD/bTmjSkGTmgqmvtQEeqRzcq7TCaXVd d0jg== X-Gm-Message-State: AOUpUlF+aK81jXo66eJUIEFYUk/ADK6IzdC41dvLrRA3mNZkQ/HFjIIb Nl+Pm2KavfJVU497R7D+fAg= X-Google-Smtp-Source: AA+uWPyrgWEe0BDRPLRiHcqAS4iph9P7O6ot9cgsDxRnNKswe1R3x+eMYkm+nT3Yzd7zxB2EJS0oAA== X-Received: by 2002:a6b:2c82:: with SMTP id s124-v6mr5787231ios.136.1531940270963; Wed, 18 Jul 2018 11:57:50 -0700 (PDT) Received: from [31.133.150.114] (dhcp-9672.meeting.ietf.org. [31.133.150.114]) by smtp.gmail.com with ESMTPSA id f204-v6sm739849itc.13.2018.07.18.11.57.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 11:57:50 -0700 (PDT) To: Sean Leonard , Carsten Bormann Cc: cbor@ietf.org, Laurence Lundblade References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> From: Brian E Carpenter Message-ID: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> Date: Thu, 19 Jul 2018 06:57:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 18:58:05 -0000 > If you really want a preferred serialization for CBOR, I do believe tha= t the whole UTF-8 encoding thing has to be addressed. Otherwise, you trea= t UTF-8 strings exactly like byte strings, but that is not helpful to a r= elying application higher up in the stack. We hit a very mild form of this problem while designing the GRASP protoco= l, which is encoded in CBOR. After seeking advice from the gods of internati= onalization, we concluded that the only viable solution was indeed "treat UTF-8 string= s exactly like byte strings." I would **very** strongly suggest keeping the= many horrible issues of UTF-8 canonicalization out of the already complex issues of CBOR canonicalization. It's a layer 7 problem and should be left there. (One result in GRASP is that if someone wants to name a GRASP objective with a name that includes Cyrillic "=D1=81", the "pile-of-poo" symbol and= several line feeds, they are welcome to do so, but it's not a protocol pr= oblem.) Regards Brian On 19/07/2018 01:17, Sean Leonard wrote: >=20 >=20 >> On Jul 18, 2018, at 3:30 AM, Carsten Bormann wrote: >> >> >> >>> On Jul 18, 2018, at 01:05, Sean Leonard wrote:= >>> >>> >>> I also think that major type 3 needs more work in its preferred seria= lization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D as that= term is used in the Unicode standard. The current text of RFC7049 does n= ot require that the UTF-8 be well-formed. Shortest encoding is one aspect= of being well-formed, but not the only aspect. >> >> I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. >> >> CBOR does not require any specific form (e.g. normalization form) of t= he UTF-8 strings, but they do have to be UTF-8 strings. >=20 > https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf >=20 > D85: A Unicode code unit sequence that purports to be in a Unicode enco= ding form is called well-formed if and only if it does follow the specifi= cation of that Unicode encoding form. > Summary of points: >=20 > * Must be in shortest encoded form (no C0 5E stuff: identical criteria = as CBOR shortest encoded form, therefore not objectionable) > * No =E2=80=9Cill-formed subsequences=E2=80=9D (example given in D86 is= <41 C2 C3 B1 42>: C2 is ill-formed because it needs to have a value in t= he range 00-7F after it to correspond to a Unicode scalar value) > * UTF-8 must only encode =E2=80=9CUnicode scalar values=E2=80=9D: this = is a little opaque but a =E2=80=9CUnicode scalar value=E2=80=9D (D76) is = any code point (0 - 1FFFFF) *except* surrogate code points. Therefore, we= ll-formed UTF-8 cannot contain U+D800-U+DFFF. >=20 > See also WTF-8: > https://simonsapin.github.io/wtf-8/ >=20 > This requirement for well-formed UTF-8 is both obvious and extremely co= unterintuitive (and potentially unproductive), depending on how you look = at it. It is =E2=80=9Cobvious=E2=80=9D because one expects the shortest e= ncoded form, and if you encode a surrogate pair (one U+D800-U+DB00, follo= wed by one U+DC00-U+DFFF), you get 6 bytes of UTF-8 to represent a Unicod= e scalar value in the range U+10000-U+1FFFFF, instead of 4 bytes of UTF-8= where the first byte starts with F0-F4. (Also: F5-FF can never appear in= UTF-8. It would have been an interesting and perfectly valid design choi= ce to use FF as a terminal marker for an indefinite-length UTF-8 string i= n CBOR.) >=20 > But it is counterintuitive and unproductive, because many software stac= ks encode Unicode strings in UTF-16 but permit unpaired surrogates, effec= tively treating =E2=80=9CUnicode=E2=80=9D strings as arbitrary sequences = of 16-bits. These products include JavaScript generally, Windows, Java, M= ozilla (somewhat, depends on the boundary interface), etc. See Section 8.= 2 of RFC 7159. >=20 > It could be a security issue to let such exceptional subsequences to go= through, but probably the worst that will happen in practice is that emo= ji get snuck through an emoji scrubber. =F0=9F=98=82 >=20 > The bigger point I guess is that to the extent that CBOR is a strict su= perset of JSON, JSON does not formally prohibit unpaired surrogates. (It = prohibits unpaired surrogates, arguably, by requiring the JSON source tex= t to be in UTF-8, UTF-16, or UTF-32, but it explicitly enables unpaired s= urrogates in escaped form, see Section 8.2 of RFC 7159.) In fact, to the = extent that JSON is used as the serialization format between two implemen= tations that both use 16-bit =E2=80=9CUTF-16=E2=80=9D without enforcing s= urrogate pairing, support for unpaired surrogates in JSON is probably nec= essary for interoperability. One such reason is because if a naive implem= entation splits a Unicode string right between surrogate pairs, the imple= mentation ought also to reassemble the string properly which will make it= good again rather than delete the temporarily offending code points. >=20 > If you really want a preferred serialization for CBOR, I do believe tha= t the whole UTF-8 encoding thing has to be addressed. Otherwise, you trea= t UTF-8 strings exactly like byte strings, but that is not helpful to a r= elying application higher up in the stack. >=20 > Sean >=20 >> >> Consistent encoding requirements of an application may go beyond those= of just the CBOR serialization and may include requirements on the data = in the data items. E.g., a case-insensitive application may need to conv= ert strings to lower-case. Or a Unicode application may need to normaliz= e (in NFC, one might hope). Neither is the business of CBOR, which is ju= st carrying the text strings. And constrained nodes usually can=E2=80=99= t really solve the LETTER BEH WITH HAMZA ABOVE issue anyway. >> >>>> # If there is more than one serialization variant available that dif= fer in overall length, the preferred serialization uses the shortest one.= >>>> >>>> Now, indefinite actually is shorter for, e.g., arrays of more than 2= 55 elements, so the preference for definite should be explicitly *higher = priority* than the overall length. On the other hand, the preference for= definite is *weaker* =E2=80=94 there are many good reasons to go to inde= finite length in particular for arrays and maps (otherwise we wouldn=E2=80= =99t have that variant!). >>> >>> I do not know if being in definite form is desirable for this =E2=80=9C= preferred serialization=E2=80=9D business, for reasons that Carsten menti= ons. Forcing maps and arrays to be in definite form requires that the num= ber of items be known in advance. (This is better than ASN.1, which requi= res pre-serializing all of the elements, but is still not the best.) Inde= finite form has notable advantages, including having an encoder be able t= o stream out content infinitely (think=E2=80=A6indefinite media stream, i= ndefinite sensor stream, etc.). >> >> I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. But = in many cases array and map sizes are known, and in that case (i.e., abse= nce of a good reason to go non-preferred) definite is still preferred. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Wed Jul 18 12:09:44 2018 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 40521130F96 for ; Wed, 18 Jul 2018 12:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pl0SK839wlz0 for ; Wed, 18 Jul 2018 12:09:39 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42467130F89 for ; Wed, 18 Jul 2018 12:09:39 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6D8EA2750C; Wed, 18 Jul 2018 15:09:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> Date: Wed, 18 Jul 2018 15:09:36 -0400 Cc: Carsten Bormann , cbor@ietf.org, Laurence Lundblade Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 19:09:44 -0000 > On Jul 18, 2018, at 2:57 PM, Brian E Carpenter = wrote: >=20 >> If you really want a preferred serialization for CBOR, I do believe = that the whole UTF-8 encoding thing has to be addressed. Otherwise, you = treat UTF-8 strings exactly like byte strings, but that is not helpful = to a relying application higher up in the stack. >=20 > We hit a very mild form of this problem while designing the GRASP = protocol, > which is encoded in CBOR. After seeking advice from the gods of = internationalization, > we concluded that the only viable solution was indeed "treat UTF-8 = strings > exactly like byte strings." I would **very** strongly suggest keeping = the many > horrible issues of UTF-8 canonicalization out of the already complex > issues of CBOR canonicalization. It's a layer 7 problem and should be > left there. The issues I pointed out are wellformedness/definitional issues. A = string of bytes that includes 0xFF is not UTF-8 in any way, shape, or = form; it is an error on the same level as a definite-length CBOR map or = array having 0xFF inside. (No UTF-8 can include 0xFF, not even = ill-formed ones, since even in the legacy range of ISO 10646 going to = U+7FFFFFFF, the first byte has to be 0b1111110x, which is not 0xFF.) = Please also do not confuse =E2=80=9Ccanonicalization=E2=80=9D with = =E2=80=9CUnicode Normalization Forms=E2=80=9D, which are a totally = different thing (and I agree, normalization is a higher level problem). If integers are going to have a =E2=80=9Cpreferred serialization=E2=80=9D,= then UTF-8 strings also ought to have a =E2=80=9Cpreferred = serialization=E2=80=9D. Symmetry. Regards, Sean >=20 > (One result in GRASP is that if someone wants to name a GRASP = objective > with a name that includes Cyrillic "=D1=81", the "pile-of-poo" symbol = and > several line feeds, they are welcome to do so, but it's not a protocol = problem.) >=20 > Regards > Brian >=20 > On 19/07/2018 01:17, Sean Leonard wrote: >>=20 >>=20 >>> On Jul 18, 2018, at 3:30 AM, Carsten Bormann wrote: >>>=20 >>>=20 >>>=20 >>>> On Jul 18, 2018, at 01:05, Sean Leonard = wrote: >>>>=20 >>>>=20 >>>> I also think that major type 3 needs more work in its preferred = serialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D = as that term is used in the Unicode standard. The current text of = RFC7049 does not require that the UTF-8 be well-formed. Shortest = encoding is one aspect of being well-formed, but not the only aspect. >>>=20 >>> I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. >>>=20 >>> CBOR does not require any specific form (e.g. normalization form) of = the UTF-8 strings, but they do have to be UTF-8 strings. >>=20 >> https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf >>=20 >> D85: A Unicode code unit sequence that purports to be in a Unicode = encoding form is called well-formed if and only if it does follow the = specification of that Unicode encoding form. >> Summary of points: >>=20 >> * Must be in shortest encoded form (no C0 5E stuff: identical = criteria as CBOR shortest encoded form, therefore not objectionable) >> * No =E2=80=9Cill-formed subsequences=E2=80=9D (example given in D86 = is <41 C2 C3 B1 42>: C2 is ill-formed because it needs to have a value = in the range 00-7F after it to correspond to a Unicode scalar value) >> * UTF-8 must only encode =E2=80=9CUnicode scalar values=E2=80=9D: = this is a little opaque but a =E2=80=9CUnicode scalar value=E2=80=9D = (D76) is any code point (0 - 1FFFFF) *except* surrogate code points. = Therefore, well-formed UTF-8 cannot contain U+D800-U+DFFF. >>=20 >> See also WTF-8: >> https://simonsapin.github.io/wtf-8/ >>=20 >> This requirement for well-formed UTF-8 is both obvious and extremely = counterintuitive (and potentially unproductive), depending on how you = look at it. It is =E2=80=9Cobvious=E2=80=9D because one expects the = shortest encoded form, and if you encode a surrogate pair (one = U+D800-U+DB00, followed by one U+DC00-U+DFFF), you get 6 bytes of UTF-8 = to represent a Unicode scalar value in the range U+10000-U+1FFFFF, = instead of 4 bytes of UTF-8 where the first byte starts with F0-F4. = (Also: F5-FF can never appear in UTF-8. It would have been an = interesting and perfectly valid design choice to use FF as a terminal = marker for an indefinite-length UTF-8 string in CBOR.) >>=20 >> But it is counterintuitive and unproductive, because many software = stacks encode Unicode strings in UTF-16 but permit unpaired surrogates, = effectively treating =E2=80=9CUnicode=E2=80=9D strings as arbitrary = sequences of 16-bits. These products include JavaScript generally, = Windows, Java, Mozilla (somewhat, depends on the boundary interface), = etc. See Section 8.2 of RFC 7159. >>=20 >> It could be a security issue to let such exceptional subsequences to = go through, but probably the worst that will happen in practice is that = emoji get snuck through an emoji scrubber. =F0=9F=98=82 >>=20 >> The bigger point I guess is that to the extent that CBOR is a strict = superset of JSON, JSON does not formally prohibit unpaired surrogates. = (It prohibits unpaired surrogates, arguably, by requiring the JSON = source text to be in UTF-8, UTF-16, or UTF-32, but it explicitly enables = unpaired surrogates in escaped form, see Section 8.2 of RFC 7159.) In = fact, to the extent that JSON is used as the serialization format = between two implementations that both use 16-bit =E2=80=9CUTF-16=E2=80=9D = without enforcing surrogate pairing, support for unpaired surrogates in = JSON is probably necessary for interoperability. One such reason is = because if a naive implementation splits a Unicode string right between = surrogate pairs, the implementation ought also to reassemble the string = properly which will make it good again rather than delete the = temporarily offending code points. >>=20 >> If you really want a preferred serialization for CBOR, I do believe = that the whole UTF-8 encoding thing has to be addressed. Otherwise, you = treat UTF-8 strings exactly like byte strings, but that is not helpful = to a relying application higher up in the stack. >>=20 >> Sean >>=20 >>>=20 >>> Consistent encoding requirements of an application may go beyond = those of just the CBOR serialization and may include requirements on the = data in the data items. E.g., a case-insensitive application may need = to convert strings to lower-case. Or a Unicode application may need to = normalize (in NFC, one might hope). Neither is the business of CBOR, = which is just carrying the text strings. And constrained nodes usually = can=E2=80=99t really solve the LETTER BEH WITH HAMZA ABOVE issue anyway. >>>=20 >>>>> # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >>>>>=20 >>>>> Now, indefinite actually is shorter for, e.g., arrays of more than = 255 elements, so the preference for definite should be explicitly = *higher priority* than the overall length. On the other hand, the = preference for definite is *weaker* =E2=80=94 there are many good = reasons to go to indefinite length in particular for arrays and maps = (otherwise we wouldn=E2=80=99t have that variant!). >>>>=20 >>>> I do not know if being in definite form is desirable for this = =E2=80=9Cpreferred serialization=E2=80=9D business, for reasons that = Carsten mentions. Forcing maps and arrays to be in definite form = requires that the number of items be known in advance. (This is better = than ASN.1, which requires pre-serializing all of the elements, but is = still not the best.) Indefinite form has notable advantages, including = having an encoder be able to stream out content infinitely = (think=E2=80=A6indefinite media stream, indefinite sensor stream, etc.). >>>=20 >>> I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. = But in many cases array and map sizes are known, and in that case (i.e., = absence of a good reason to go non-preferred) definite is still = preferred. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >>=20 >=20 From nobody Wed Jul 18 12:48:09 2018 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 BD48E130ED4 for ; Wed, 18 Jul 2018 12:48:07 -0700 (PDT) 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_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 Kq7K0TTBU-B2 for ; Wed, 18 Jul 2018 12:48:05 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 87F5B130E47 for ; Wed, 18 Jul 2018 12:48:05 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 12:48:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,371,1526367600"; d="scan'208";a="246350960" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 18 Jul 2018 12:47:48 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 12:47:21 -0700 From: Thiago Macieira To: CC: Sean Leonard Date: Wed, 18 Jul 2018 12:47:20 -0700 Message-ID: <1928710.SkNU6O7J7G@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 19:48:08 -0000 On Wednesday, 18 July 2018 12:09:36 PDT Sean Leonard wrote: > The issues I pointed out are wellformedness/definitional issues. A string= of > bytes that includes 0xFF is not UTF-8 in any way, shape, or form; it is an > error on the same level as a definite-length CBOR map or array having 0xFF > inside. (No UTF-8 can include 0xFF, not even ill-formed ones, since even = in > the legacy range of ISO 10646 going to U+7FFFFFFF, the first byte has to = be > 0b1111110x, which is not 0xFF.) Please also do not confuse > =E2=80=9Ccanonicalization=E2=80=9D with =E2=80=9CUnicode Normalization Fo= rms=E2=80=9D, which are a totally > different thing (and I agree, normalization is a higher level problem). >=20 > If integers are going to have a =E2=80=9Cpreferred serialization=E2=80=9D= , then UTF-8 > strings also ought to have a =E2=80=9Cpreferred serialization=E2=80=9D. S= ymmetry. That's a different thing, though. RFC 7049 currently only places UTF-8=20 validation in the Strict Mode, so some implementations treat it as a byte=20 array and will not perform any inspection on the content. Other implementations will, especially those that decode the content into=20 their internal string representations. Those cannot cope with a \xFF in the= =20 UTF-8 content or, for that matter, anything higher than \xF8. They will als= o=20 reject overlong encodings (\xC1 \x81) and UTF-8 decoding into UTF-16 surrog= ate=20 code units. Therefore, for interoperability, encoders must =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Wed Jul 18 13:14:14 2018 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 AAF9713120B for ; Wed, 18 Jul 2018 13:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPjBz0UkURsY for ; Wed, 18 Jul 2018 13:14:03 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F28E131068 for ; Wed, 18 Jul 2018 13:14:03 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q9-v6so5153655ioj.8 for ; Wed, 18 Jul 2018 13:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M4l9baBEpuVo5/CLYpKttusl/5V/Smxe5dyuF8bJmpo=; b=G+74BjgEEVPGbhiBGrWuU5PpaRKl5+wROOybfLDNwGs5ZlB64ED68DuQZx7XXrrNOC 3ZO76rhwPsXmXU5Sqzn3EAa3sBNQKb09APtdsEdbXTB51pwsCig5pHgvbsL0CFwZ65SH mvdvDu7eAm3PmSlJbpusYLO1x101eLLIvzNzKbBbNY8cqUcBbJLPSAcxPHPRJFDs9dFH 1kmW43dLcho69Qk0MZPiSe/tjAcqgu32Oddqq2/NFDv3kI1cvEa5wMZeinr3i1itqJDB AT/hFLoJyXdMonXz3FDe6eHHDqE0t6t5Nuxj7CnWAyzthNc2VBMqt7PXjzXUAc3IMB4U inTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M4l9baBEpuVo5/CLYpKttusl/5V/Smxe5dyuF8bJmpo=; b=UpGqr+LGGarStUtx0XAaH8SQ7a1oaNRbIFJXJDM7aLJJDkxdHtto6/HwwVVmLdDU6U WfBo9sqGJKWdOgjv8fmPdEqZkGCmwtLm5k928dUq/xDojXy6sEFDWjkkCboJW7bDXbTk RVVpJEg2Fq1BqPaXjj64nJ5I3iNBjLycAq7AB+CO75j7q3DqemWcMiOQhSsuvdMkZ9By zG8cVYEzoiD09bmMCQ8nRa7MQp36xlnjbZPEuciLaIA0nuX77uhz4VzmoTbu09p4VLpb ZBLhUR5+yz4FEeKiddiJLHywURKgtM1Ssp1T3fc4flGVvjObNoCgQb5qrUbC5JoVRQkC Pr1g== X-Gm-Message-State: AOUpUlGBoUeAE81C9rYfphWy7Rhgz2sCvmchzde/hS12NwThOxbsltx7 biVgI0bYvaSAN0oMWXJuZgw= X-Google-Smtp-Source: AA+uWPye2VUIgi4aOKN0fmMqFmp9E2MnFgcjeWjRE5bZFcQekH8zoi4MRQxWEnS3OSCeR1oIaXzXVA== X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr6216176ioa.168.1531944842653; Wed, 18 Jul 2018 13:14:02 -0700 (PDT) Received: from [31.133.150.114] (dhcp-9672.meeting.ietf.org. [31.133.150.114]) by smtp.gmail.com with ESMTPSA id h20-v6sm1909166iob.44.2018.07.18.13.14.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 13:14:01 -0700 (PDT) To: Sean Leonard Cc: Carsten Bormann , cbor@ietf.org, Laurence Lundblade References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> From: Brian E Carpenter Message-ID: <6d2b71c0-8e11-d8d7-2a0c-0cc7c161fcbc@gmail.com> Date: Thu, 19 Jul 2018 08:14:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:14:12 -0000 On 19/07/2018 07:09, Sean Leonard wrote:>> On Jul 18, 2018, at 2:57 PM, B= rian E Carpenter wrote: >> >>> If you really want a preferred serialization for CBOR, I do believe t= hat the whole UTF-8 encoding thing has to be addressed. Otherwise, you tr= eat UTF-8 strings exactly like byte strings, but that is not helpful to a= relying application higher up in the stack. >> >> We hit a very mild form of this problem while designing the GRASP prot= ocol, >> which is encoded in CBOR. After seeking advice from the gods of intern= ationalization, >> we concluded that the only viable solution was indeed "treat UTF-8 str= ings >> exactly like byte strings." I would **very** strongly suggest keeping = the many >> horrible issues of UTF-8 canonicalization out of the already complex >> issues of CBOR canonicalization. It's a layer 7 problem and should be >> left there. >=20 > The issues I pointed out are wellformedness/definitional issues. A stri= ng of bytes that includes 0xFF is not UTF-8 in any way, shape, or form; i= t is an error on the same level as a definite-length CBOR map or array ha= ving 0xFF inside. (No UTF-8 can include 0xFF, not even ill-formed ones, s= ince even in the legacy range of ISO 10646 going to U+7FFFFFFF, the first= byte has to be 0b1111110x, which is not 0xFF.) Please also do not confus= e =E2=80=9Ccanonicalization=E2=80=9D with =E2=80=9CUnicode Normalization = Forms=E2=80=9D, which are a totally different thing (and I agree, normali= zation is a higher level problem). Sorry about that terminology glitch, but it doesn't change what I'm tryin= g to say. So, if we simply say "treat UTF-8 strings exactly like byte strings"= , and if the sender sends an invalid UTF-8 string, that's exactly what the receiver will get. Are you saying that the CBOR encoder should be looking= for invalid UTF-8? =20 > If integers are going to have a =E2=80=9Cpreferred serialization=E2=80=9D= , then UTF-8 strings also ought to have a =E2=80=9Cpreferred serializatio= n=E2=80=9D. Symmetry. Sure. And I think it should be "treat UTF-8 strings exactly like byte str= ings". Isn't that what running code does?=20 Regards Brian >=20 > Regards, >=20 > Sean >=20 >> >> (One result in GRASP is that if someone wants to name a GRASP objectiv= e >> with a name that includes Cyrillic "=D1=81", the "pile-of-poo" symbol = and >> several line feeds, they are welcome to do so, but it's not a protocol= problem.) >> >> Regards >> Brian >> >> On 19/07/2018 01:17, Sean Leonard wrote: >>> >>> >>>> On Jul 18, 2018, at 3:30 AM, Carsten Bormann wrote: >>>> >>>> >>>> >>>>> On Jul 18, 2018, at 01:05, Sean Leonard wrot= e: >>>>> >>>>> >>>>> I also think that major type 3 needs more work in its preferred ser= ialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D as th= at term is used in the Unicode standard. The current text of RFC7049 does= not require that the UTF-8 be well-formed. Shortest encoding is one aspe= ct of being well-formed, but not the only aspect. >>>> >>>> I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. >>>> >>>> CBOR does not require any specific form (e.g. normalization form) of= the UTF-8 strings, but they do have to be UTF-8 strings. >>> >>> https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf >>> >>> D85: A Unicode code unit sequence that purports to be in a Unicode en= coding form is called well-formed if and only if it does follow the speci= fication of that Unicode encoding form. >>> Summary of points: >>> >>> * Must be in shortest encoded form (no C0 5E stuff: identical criteri= a as CBOR shortest encoded form, therefore not objectionable) >>> * No =E2=80=9Cill-formed subsequences=E2=80=9D (example given in D86 = is <41 C2 C3 B1 42>: C2 is ill-formed because it needs to have a value in= the range 00-7F after it to correspond to a Unicode scalar value) >>> * UTF-8 must only encode =E2=80=9CUnicode scalar values=E2=80=9D: thi= s is a little opaque but a =E2=80=9CUnicode scalar value=E2=80=9D (D76) i= s any code point (0 - 1FFFFF) *except* surrogate code points. Therefore, = well-formed UTF-8 cannot contain U+D800-U+DFFF. >>> >>> See also WTF-8: >>> https://simonsapin.github.io/wtf-8/ >>> >>> This requirement for well-formed UTF-8 is both obvious and extremely = counterintuitive (and potentially unproductive), depending on how you loo= k at it. It is =E2=80=9Cobvious=E2=80=9D because one expects the shortest= encoded form, and if you encode a surrogate pair (one U+D800-U+DB00, fol= lowed by one U+DC00-U+DFFF), you get 6 bytes of UTF-8 to represent a Unic= ode scalar value in the range U+10000-U+1FFFFF, instead of 4 bytes of UTF= -8 where the first byte starts with F0-F4. (Also: F5-FF can never appear = in UTF-8. It would have been an interesting and perfectly valid design ch= oice to use FF as a terminal marker for an indefinite-length UTF-8 string= in CBOR.) >>> >>> But it is counterintuitive and unproductive, because many software st= acks encode Unicode strings in UTF-16 but permit unpaired surrogates, eff= ectively treating =E2=80=9CUnicode=E2=80=9D strings as arbitrary sequence= s of 16-bits. These products include JavaScript generally, Windows, Java,= Mozilla (somewhat, depends on the boundary interface), etc. See Section = 8.2 of RFC 7159. >>> >>> It could be a security issue to let such exceptional subsequences to = go through, but probably the worst that will happen in practice is that e= moji get snuck through an emoji scrubber. =F0=9F=98=82 >>> >>> The bigger point I guess is that to the extent that CBOR is a strict = superset of JSON, JSON does not formally prohibit unpaired surrogates. (I= t prohibits unpaired surrogates, arguably, by requiring the JSON source t= ext to be in UTF-8, UTF-16, or UTF-32, but it explicitly enables unpaired= surrogates in escaped form, see Section 8.2 of RFC 7159.) In fact, to th= e extent that JSON is used as the serialization format between two implem= entations that both use 16-bit =E2=80=9CUTF-16=E2=80=9D without enforcing= surrogate pairing, support for unpaired surrogates in JSON is probably n= ecessary for interoperability. One such reason is because if a naive impl= ementation splits a Unicode string right between surrogate pairs, the imp= lementation ought also to reassemble the string properly which will make = it good again rather than delete the temporarily offending code points. >>> >>> If you really want a preferred serialization for CBOR, I do believe t= hat the whole UTF-8 encoding thing has to be addressed. Otherwise, you tr= eat UTF-8 strings exactly like byte strings, but that is not helpful to a= relying application higher up in the stack. >>> >>> Sean >>> >>>> >>>> Consistent encoding requirements of an application may go beyond tho= se of just the CBOR serialization and may include requirements on the dat= a in the data items. E.g., a case-insensitive application may need to co= nvert strings to lower-case. Or a Unicode application may need to normal= ize (in NFC, one might hope). Neither is the business of CBOR, which is = just carrying the text strings. And constrained nodes usually can=E2=80=99= t really solve the LETTER BEH WITH HAMZA ABOVE issue anyway. >>>> >>>>>> # If there is more than one serialization variant available that d= iffer in overall length, the preferred serialization uses the shortest on= e. >>>>>> >>>>>> Now, indefinite actually is shorter for, e.g., arrays of more than= 255 elements, so the preference for definite should be explicitly *highe= r priority* than the overall length. On the other hand, the preference f= or definite is *weaker* =E2=80=94 there are many good reasons to go to in= definite length in particular for arrays and maps (otherwise we wouldn=E2= =80=99t have that variant!). >>>>> >>>>> I do not know if being in definite form is desirable for this =E2=80= =9Cpreferred serialization=E2=80=9D business, for reasons that Carsten me= ntions. Forcing maps and arrays to be in definite form requires that the = number of items be known in advance. (This is better than ASN.1, which re= quires pre-serializing all of the elements, but is still not the best.) I= ndefinite form has notable advantages, including having an encoder be abl= e to stream out content infinitely (think=E2=80=A6indefinite media stream= , indefinite sensor stream, etc.). >>>> >>>> I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. Bu= t in many cases array and map sizes are known, and in that case (i.e., ab= sence of a good reason to go non-preferred) definite is still preferred. >>>> >>>> Gr=C3=BC=C3=9Fe, Carsten >>>> >>> >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>> >> >=20 >=20 From nobody Wed Jul 18 13:23:55 2018 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 3FBCD131006 for ; Wed, 18 Jul 2018 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MiERwb7Q3Xip for ; Wed, 18 Jul 2018 13:23:48 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48547130E3A for ; Wed, 18 Jul 2018 13:23:48 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A4A922754B; Wed, 18 Jul 2018 16:23:44 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: <1928710.SkNU6O7J7G@tjmaciei-mobl1> Date: Wed, 18 Jul 2018 16:23:42 -0400 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <70140FC9-DB53-49E2-81F2-D30902600FC3@seantek.com> References: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> <1928710.SkNU6O7J7G@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:23:51 -0000 > On Jul 18, 2018, at 3:47 PM, Thiago Macieira = wrote: >=20 > On Wednesday, 18 July 2018 12:09:36 PDT Sean Leonard wrote: >> The issues I pointed out are wellformedness/definitional issues. A = string of >> bytes that includes 0xFF is not UTF-8 in any way, shape, or form; it = is an >> error on the same level as a definite-length CBOR map or array having = 0xFF >> inside. (No UTF-8 can include 0xFF, not even ill-formed ones, since = even in >> the legacy range of ISO 10646 going to U+7FFFFFFF, the first byte has = to be >> 0b1111110x, which is not 0xFF.) Please also do not confuse >> =E2=80=9Ccanonicalization=E2=80=9D with =E2=80=9CUnicode = Normalization Forms=E2=80=9D, which are a totally >> different thing (and I agree, normalization is a higher level = problem). >>=20 >> If integers are going to have a =E2=80=9Cpreferred serialization=E2=80=9D= , then UTF-8 >> strings also ought to have a =E2=80=9Cpreferred serialization=E2=80=9D.= Symmetry. >=20 > That's a different thing, though. RFC 7049 currently only places UTF-8=20= > validation in the Strict Mode, so some implementations treat it as a = byte=20 > array and will not perform any inspection on the content. >=20 > Other implementations will, especially those that decode the content = into=20 > their internal string representations. Those cannot cope with a \xFF = in the=20 > UTF-8 content or, for that matter, anything higher than \xF8. They = will also=20 > reject overlong encodings (\xC1 \x81) and UTF-8 decoding into UTF-16 = surrogate=20 > code units. >=20 > Therefore, for interoperability, encoders must Did you need to finish that sentence or paragraph? Just checking. :-) Sean From nobody Wed Jul 18 13:29:46 2018 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 2E385130E74 for ; Wed, 18 Jul 2018 13:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CDLoHJxE5mht for ; Wed, 18 Jul 2018 13:29:42 -0700 (PDT) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 6E5BC130E3A for ; Wed, 18 Jul 2018 13:29:42 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 13:29:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,371,1526367600"; d="scan'208";a="58745986" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga006.jf.intel.com with ESMTP; 18 Jul 2018 13:29:39 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 13:29:38 -0700 From: Thiago Macieira To: Sean Leonard CC: Date: Wed, 18 Jul 2018 13:29:38 -0700 Message-ID: <18125686.NTxZSazurH@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <70140FC9-DB53-49E2-81F2-D30902600FC3@seantek.com> References: <1928710.SkNU6O7J7G@tjmaciei-mobl1> <70140FC9-DB53-49E2-81F2-D30902600FC3@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:29:44 -0000 On Wednesday, 18 July 2018 13:23:42 PDT Sean Leonard wrote: > > Therefore, for interoperability, encoders must > > Did you need to finish that sentence or paragraph? Just checking. ... not send malformed UTF-8 strings. That's the same for all Strict Mode requirements. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Wed Jul 18 13:30:42 2018 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 1FCB5130EA5 for ; Wed, 18 Jul 2018 13:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PzBsJg3VwSNA for ; Wed, 18 Jul 2018 13:30:38 -0700 (PDT) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F3C130E3A for ; Wed, 18 Jul 2018 13:30:38 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 13:30:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,371,1526367600"; d="scan'208";a="58746244" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga006.jf.intel.com with ESMTP; 18 Jul 2018 13:30:28 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 13:30:28 -0700 From: Thiago Macieira To: Date: Wed, 18 Jul 2018 13:30:28 -0700 Message-ID: <38401440.7tWFtPP2jh@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <6d2b71c0-8e11-d8d7-2a0c-0cc7c161fcbc@gmail.com> References: <6d2b71c0-8e11-d8d7-2a0c-0cc7c161fcbc@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:30:40 -0000 On Wednesday, 18 July 2018 13:14:02 PDT Brian E Carpenter wrote: > Sorry about that terminology glitch, but it doesn't change what I'm trying > to say. So, if we simply say "treat UTF-8 strings exactly like byte > strings", and if the sender sends an invalid UTF-8 string, that's exactly > what the receiver will get. Are you saying that the CBOR encoder should be > looking for invalid UTF-8? It should be actively avoiding them, if possible. If an invalid UTF-8 string is sent, the receiver may not get anything. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Wed Jul 18 13:43:15 2018 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 8CFF6130E21 for ; Wed, 18 Jul 2018 13:43:14 -0700 (PDT) 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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D2jLrvMyO5m for ; Wed, 18 Jul 2018 13:43:12 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 83AE6130EA5 for ; Wed, 18 Jul 2018 13:43:12 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id p17-v6so6256525itc.2 for ; Wed, 18 Jul 2018 13:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+2eExZAqUjroCzwB0LgbyfJHzxKMe5F83ApdsW53X2U=; b=m6ILNPkfK8zaZBV0FuV+6Ui/aawiajR/5Vw56hUZblawwnKP7/I+vlUDDbz19478Ty h+8GMWP7/BRb15vhFwiHQuRn3dirwLUcZ66w6znQLcYXJljEOEINMqlY8ted2RRicEx3 R5dacsxLT+RJB9lGp+KhD50VFCn/UKQC4LEATbjwab1F1WlKNkzYdhK1B5K348ACIGaG jBrYmr4bOT4qXAxyQ5pi+Ivz322wPrHv7Fbr6xo+1dpH/P1lKihhkXx1znkomdfVv30z DLYtrr0BGsunCxv91KHthZytSAY8xT5N9R94Q4MWbLA4bHkVC8xfnWfhwFbw1840ovMG xcJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+2eExZAqUjroCzwB0LgbyfJHzxKMe5F83ApdsW53X2U=; b=q2+XNNBxjMwQShnV0o16wdnFuksBCAZUcHMPFYaSmL7pQeBLQQa1bUjc0d8+hdvWjM iheK7ZnEy/EKW+RtxNGOMRjCUDZ74IgYY9TfzhmynFACgcH23QpLlMGGkCPUrvzSoHxX 6K6IjwPfE1jNMrwtgFOWRw8O4IdJXoQH3selZVCLePr3+/CBbbK52pCX6HEqPiDZ6nRM +a9SA3UNjy5sVy5XRHvfMgzN8dLa2zriAiEAIGzCnkI0wVksYFT092rqTY3DRV1OFsw+ BqMoUx3wf15QaEmMH6NGtRnb2LIJjKIm+FRvMpEM0bwz3MPb3YXHfIOioD+AHK4YJxTk vcWQ== X-Gm-Message-State: AOUpUlEpApBgHsK7yQAQzkeYil2UqTV9SPx9gLV4+coN7maBFJl4U4lS he1Qzpniw50cH32TFKF14X3vDA== X-Google-Smtp-Source: AAOMgpdimKPn7RQ/R/4Mblxc95C1Ts7qjd5jsk7qEm3O7CcrTLoYk61es9E2BzSt9E99gRu3ud+n6Q== X-Received: by 2002:a24:a342:: with SMTP id p63-v6mr3449822ite.67.1531946591882; Wed, 18 Jul 2018 13:43:11 -0700 (PDT) Received: from [31.133.150.114] (dhcp-9672.meeting.ietf.org. [31.133.150.114]) by smtp.gmail.com with ESMTPSA id l26-v6sm1933952ioh.27.2018.07.18.13.42.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 13:43:11 -0700 (PDT) To: Thiago Macieira , cbor@ietf.org Cc: Sean Leonard References: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> <1928710.SkNU6O7J7G@tjmaciei-mobl1> From: Brian E Carpenter Message-ID: <55c43f52-4b37-8923-776c-91b64abfdd1c@gmail.com> Date: Thu, 19 Jul 2018 08:42:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1928710.SkNU6O7J7G@tjmaciei-mobl1> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:43:15 -0000 On 19/07/2018 07:47, Thiago Macieira wrote: > On Wednesday, 18 July 2018 12:09:36 PDT Sean Leonard wrote: >> The issues I pointed out are wellformedness/definitional issues. A str= ing of >> bytes that includes 0xFF is not UTF-8 in any way, shape, or form; it i= s an >> error on the same level as a definite-length CBOR map or array having = 0xFF >> inside. (No UTF-8 can include 0xFF, not even ill-formed ones, since ev= en in >> the legacy range of ISO 10646 going to U+7FFFFFFF, the first byte has = to be >> 0b1111110x, which is not 0xFF.) Please also do not confuse >> =E2=80=9Ccanonicalization=E2=80=9D with =E2=80=9CUnicode Normalization= Forms=E2=80=9D, which are a totally >> different thing (and I agree, normalization is a higher level problem)= =2E >> >> If integers are going to have a =E2=80=9Cpreferred serialization=E2=80= =9D, then UTF-8 >> strings also ought to have a =E2=80=9Cpreferred serialization=E2=80=9D= =2E Symmetry. >=20 > That's a different thing, though. RFC 7049 currently only places UTF-8 = > validation in the Strict Mode, so some implementations treat it as a by= te=20 > array and will not perform any inspection on the content. That seems to be by far the most likely situation in constrained nodes. =20 > Other implementations will, especially those that decode the content in= to=20 > their internal string representations. Those cannot cope with a \xFF in= the=20 > UTF-8 content or, for that matter, anything higher than \xF8. They will= also=20 > reject overlong encodings (\xC1 \x81) and UTF-8 decoding into UTF-16 su= rrogate=20 > code units. >=20 > Therefore, for interoperability, encoders must I wish you'd finished that sentence. If you meant "encoders must check fo= r valid UTF-8" I think that's wrong; the requirement is surely that *sender= s* must send valid UTF-8. There is no requirement that the encoder validates= it, and in constrained nodes it won't. If you want to send =D0=9D=D0=B5=D0=B4= =D0=BE=D1=81=D1=82=D0=B0=D1=82=D0=BE=D1=87=D0=BD=D0=BE =D1=81=D1=80=D0=B5= =D0=B4=D1=81=D1=82=D0=B2 you'd better encode it correctly in the first place, that's all. (Also, what happened to the Postel robustness principle here?) Brian From nobody Wed Jul 18 14:10:12 2018 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 62524130F20 for ; Wed, 18 Jul 2018 14:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 noIxTeY47e-X for ; Wed, 18 Jul 2018 14:10:08 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BCD130ECB for ; Wed, 18 Jul 2018 14:10:08 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 14:10:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,371,1526367600"; d="scan'208";a="246369216" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 18 Jul 2018 14:10:08 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 14:10:07 -0700 From: Thiago Macieira To: Brian E Carpenter CC: , Sean Leonard Date: Wed, 18 Jul 2018 14:10:07 -0700 Message-ID: <2610075.BWRrE0UtWC@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <55c43f52-4b37-8923-776c-91b64abfdd1c@gmail.com> References: <1928710.SkNU6O7J7G@tjmaciei-mobl1> <55c43f52-4b37-8923-776c-91b64abfdd1c@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 21:10:10 -0000 On Wednesday, 18 July 2018 13:42:55 PDT Brian E Carpenter wrote: > (Also, what happened to the Postel robustness principle here?) Be conservative in what you send, be liberal in what you accept? Sure, the encoder should strive to not send invalid UTF-8 anymore than duplicated keys in a map. The problem here is that the liberal receiver may do one of many different things, so you can't guarantee communication: * drop the entire message on the floor (strict decoder) and report error * replace the invalid sequence with U+FFFD * discard the string, replacing with an undefined * ignore the second instance of a key in a map * overwrite the first instance of the key in a map * decode both, but have unspecified behaviour which one is found when searching -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Wed Jul 18 14:44:47 2018 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 BC157131212 for ; Wed, 18 Jul 2018 14:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1mrPDmdjhG7T for ; Wed, 18 Jul 2018 14:44:41 -0700 (PDT) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) (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 26C9913121A for ; Wed, 18 Jul 2018 14:44:41 -0700 (PDT) Received: from p3plgemwbe03-04.prod.phx3.secureserver.net ([72.167.218.132]) by :WBEOUT: with SMTP id fuEzfjT7flRZ0fuEzfDzeS; Wed, 18 Jul 2018 14:44:09 -0700 X-SID: fuEzfjT7flRZ0 Received: (qmail 143664 invoked by uid 99); 18 Jul 2018 21:44:09 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.9.42 Message-Id: <20180718144407.665a7a7059d7ee80bb4d670165c8327d.0ea1a4a906.wbe@email03.godaddy.com> From: "Doug Ewell" To: "Brian E Carpenter" , "Sean Leonard" , "Carsten Bormann" Cc: cbor@ietf.org, "Laurence Lundblade" Date: Wed, 18 Jul 2018 14:44:07 -0700 Mime-Version: 1.0 X-CMAE-Envelope: MS4wfNop+eT6GOZx4fli5sEFzcrrL5ObpUc5gKuvk/isBuvKwcYMcPLTNQhKP6XBqXIL4v/GT99ldPFLt3aO47YsHPNwEe1MzCACzL/P5236xSUTXJl2E+ka 8TzdFdskYiczuqOPXHe4HLOtLqjB2brlWel7J8CRu8CbcpVl60tiyA2Ofo1SsaYp4w+ym8eHVoyKlILBtQsGQSd7mKBYP+k4Ytg= Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 21:44:46 -0000 Sean Leonard wrote:=0A=0A> But it is counterintuitive and unproductive, bec= ause many software=0A> stacks encode Unicode strings in UTF-16 but permit u= npaired=0A> surrogates, effectively treating =E2=80=9CUnicode=E2=80=9D stri= ngs as arbitrary=0A> sequences of 16-bits. These products include JavaScrip= t generally,=0A> Windows, Java, Mozilla (somewhat, depends on the boundary = interface),=0A> etc. See Section 8.2 of RFC 7159.=0A=0APMFJI... I remain co= nvinced that virtually nobody who writes software=0Astacks that permit unpa= ired surrogates does so because they think=0Aunpaired surrogates are a grea= t thing to permit. I believe they do it=0Abecause they are confused about t= he difference between "code point" and=0A"Unicode scalar value," or they im= agine it's too hard or inefficient to=0Ahandle this in code, or they think = upstream or downstream systems will=0Aallow them, and want to remain compat= ible with such systems.=0A=0AThe same goes for 6-byte, CESU-8=E2=80=93style= encodings of supplementary=0Acharacters, such as for U= +10000. This has only been=0Ainvalid for the past seventeen years or so.=0A= =0AIn the case of a "UTF-8" string that contains one of these, Thiago's=0Ao= ption of dropping the message on the floor and reporting an error seems=0Al= ike a fine idea.=0A =0A--=0ADoug Ewell | Thornton, CO, US | ewellic.org=0A= From nobody Wed Jul 18 16:07:24 2018 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 A55BB130FFC for ; Wed, 18 Jul 2018 16:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QFjMknyINVR for ; Wed, 18 Jul 2018 16:07:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7421313100D for ; Wed, 18 Jul 2018 16:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6IN7HMS009098; Thu, 19 Jul 2018 01:07:17 +0200 (CEST) Received: from [IPv6:2001:638:708:18::8] (unknown [IPv6:2001:638:708:18::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41WCTc1kynzDWQ8; Thu, 19 Jul 2018 01:07:15 +0200 (CEST) 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: <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> Date: Wed, 18 Jul 2018 19:07:12 -0400 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 553648030.988417-e451977ffa86c6b4ee47ac62b32b0535 Content-Transfer-Encoding: quoted-printable Message-Id: <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 23:07:24 -0000 On Jul 18, 2018, at 09:17, Sean Leonard wrote: >=20 > https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf Ah. That is not relevant for RFC 7049. UTF-8 is defined in RFC 3629. I believe RFC 3629 is very clear about what is UTF-8 and what is not, = without needing to resort to gradations like well-formed but invalid = (and most of what could be considered a bit on the side of weasel-words = are caused by the abortive idea of carrying a BOM in UTF-8). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 19 10:34:57 2018 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 DB7C31310E1 for ; Thu, 19 Jul 2018 10:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFPpnp3KA1wY for ; Thu, 19 Jul 2018 10:34:46 -0700 (PDT) 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 3D70F130DC6 for ; Thu, 19 Jul 2018 10:34:46 -0700 (PDT) Received: from dhcp-8d21.meeting.ietf.org ([31.133.141.33]) by :SMTPAUTH: with ESMTPSA id gCpAfFW7Q3Zq5gCpBf5Sp5; Thu, 19 Jul 2018 10:34:45 -0700 From: Laurence Lundblade Message-Id: <63FF5DAC-3D77-4459-9FA5-471EE7B95F50@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3EDDAB94-CA95-491C-81C3-D7FDFEACA43E" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Jul 2018 13:34:44 -0400 In-Reply-To: <71E2382E-68E6-40E7-ADB0-8CF377853952@island-resort.com> Cc: cbor@ietf.org, Sean Leonard To: Carsten Bormann References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <71E2382E-68E6-40E7-ADB0-8CF377853952@island-resort.com> X-Mailer: Apple Mail (2.3445.6.18) X-CMAE-Envelope: MS4wfMZg6xlB4k6tyE3eOc44ucAql4xgJWM0+WQtHzE6NNiT1KCNpmMUv2I2Q5cev1UXs7dJEbZWNvsjxH26vgZ7ayBxWmPbbZaEgcFlg7D97Wprq1YB9g28 tIqZhp/fFu/m6Iot9z8vJRvAD+hqVYpnVTjR+2dKpTjeMxp2kTaZidE3gY4SnfBizNwpVyBkrC42HZQlmftiY66P+4KkAveFLyLGDObvhyI+F9/TqksNzkVx Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:34:55 -0000 --Apple-Mail=_3EDDAB94-CA95-491C-81C3-D7FDFEACA43E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wrote up a PR straw man for preferred serialization = . LL > On Jul 18, 2018, at 2:13 PM, Laurence Lundblade = wrote: >=20 > I am contemplating writing a PR=E2=80=A6 >=20 > Would a new sub section called =E2=80=9CPreferred Encoding=E2=80=9D be = part of "Specification for CBOR Encoding=E2=80=9D, rather than "Creating = CBOR-Based Protocols=E2=80=9D? I=E2=80=99m leaning towards the former = since it not about creating a specific protocol. >=20 > Feel dumb that I forgot to say tags should be as short as possible. >=20 > For the shortest float preference, we could use the steps described in = the 7049 canonicalization text. That is definitely some work for = implementors and may not be commonly implemented. I=E2=80=99ve checked a = few and not found an implementation.=20 >=20 > What about not requiring shortest representation for floats? It would = make the preferred encoding for floats not the smallest and not = consistent across implementations (not canonical), but might give better = interop and might be implemented more commonly. >=20 >=20 > I think we will need some description for preferred decoders too: > * must decode indefinite and definite lengths > * must decode integers and lengths encoded as 64-bits, 32-bits, = 16-bits and 8-bits (even on an 8-bit machine) > * must decode all types of float including half-precision (when I was = in Qualcomm using half-precision code in the RFC required talking to a = lawyer; writing my own would have been hard). >=20 > LL >=20 >=20 >> On Jul 17, 2018, at 10:26 PM, Carsten Bormann wrote: >>=20 >> Hi Laurence, >>=20 >> I=E2=80=99m mostly with you here, except for: >>=20 >>> On Jul 17, 2018, at 22:10, Laurence Lundblade = wrote: >>>=20 >>> Major type 5 =E2=80=94 same as major type 5; in addition sort by = keys >>=20 >> I don=E2=80=99t think the sorting can be part of the preferred = serialization, this would be consistent serialization only. It is just = too expensive. >>=20 >> Major type 6 =E2=80=94 encode the tag as short as possible >>=20 >> Major type 7 =E2=80=94 encode floating point as short as possible. >>=20 >> So maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D = and just state it as a general rule, because it is a general rule. >>=20 >> # If there is more than one serialization variant available that = differ in overall length, the preferred serialization uses the shortest = one. >>=20 >> Now, indefinite actually is shorter for, e.g., arrays of more than = 255 elements, so the preference for definite should be explicitly = *higher priority* than the overall length. On the other hand, the = preference for definite is *weaker* =E2=80=94 there are many good = reasons to go to indefinite length in particular for arrays and maps = (otherwise we wouldn=E2=80=99t have that variant!). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_3EDDAB94-CA95-491C-81C3-D7FDFEACA43E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wrote up a PR straw man for preferred serialization.

LL


On Jul 18, 2018, at 2:13 PM, = Laurence Lundblade <lgl@island-resort.com> wrote:

I am = contemplating writing a PR=E2=80=A6

Would a = new sub section called =E2=80=9CPreferred Encoding=E2=80=9D be part of = "Specification for CBOR Encoding=E2=80=9D, rather than "Creating = CBOR-Based Protocols=E2=80=9D? I=E2=80=99m leaning towards the former = since it not about creating a specific protocol.

Feel dumb that I forgot to say tags should be as short as = possible.

For the shortest float = preference, we could use the steps described in the 7049 = canonicalization text. That is definitely some work for implementors and = may not be commonly implemented. I=E2=80=99ve checked a few and not = found an implementation.

What about not = requiring shortest representation for floats? It would make the = preferred encoding for floats not the smallest and not consistent across = implementations (not canonical), but might give better interop and might = be implemented more commonly.


I think we will need some description for preferred decoders = too:
* must decode indefinite and definite lengths
* must decode integers and lengths encoded as 64-bits, = 32-bits, 16-bits and 8-bits (even on an 8-bit machine)
* = must decode all types of float including half-precision (when I was in = Qualcomm using half-precision code in the RFC required talking to a = lawyer; writing my own would have been hard).

LL


On Jul 17, 2018, at 10:26 PM, Carsten Bormann = <cabo@tzi.org> = wrote:

Hi Laurence,

I=E2=80=99m mostly with you here, except for:
On Jul 17, 2018, at = 22:10, Laurence Lundblade <lgl@island-resort.com> wrote:

Major type 5 =E2=80=94 same as major type 5; in addition sort = by keys

I don=E2=80=99t think = the sorting can be part of the preferred serialization, this would be = consistent serialization only.  It is just too expensive.

Major type 6 =E2=80=94 encode the tag as short = as possible

Major type 7 =E2=80=94 encode = floating point as short as possible.

So = maybe we can factor out that =E2=80=9Cas short as possible=E2=80=9D and = just state it as a general rule, because it is a general rule.

# If there is more than one serialization = variant available that differ in overall length, the preferred = serialization uses the shortest one.

Now, = indefinite actually is shorter for, e.g., arrays of more than 255 = elements, so the preference for definite should be explicitly *higher = priority* than the overall length.  On the other hand, the = preference for definite is *weaker* =E2=80=94 there are many good = reasons to go to indefinite length in particular for arrays and maps = (otherwise we wouldn=E2=80=99t have that variant!).

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

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

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

= --Apple-Mail=_3EDDAB94-CA95-491C-81C3-D7FDFEACA43E-- From nobody Sun Jul 22 06:13:15 2018 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 BC4F2130DC1 for ; Sun, 22 Jul 2018 06:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RhJHmeivjI5P for ; Sun, 22 Jul 2018 06:13:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC28B12D7F8 for ; Sun, 22 Jul 2018 06:13:09 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 22 Jul 2018 06:09:31 -0700 From: Jim Schaad To: 'Brian E Carpenter' , 'Sean Leonard' , 'Carsten Bormann' CC: , 'Laurence Lundblade' References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> In-Reply-To: <79d7d5a1-57ba-a09d-0aa6-182a240ca90b@gmail.com> Date: Sun, 22 Jul 2018 06:13:01 -0700 Message-ID: <00cf01d421bd$b9962f30$2cc28d90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLIfzXdqD17XquTswgVin1z14S7+QJmSIoeAip/FnMBwK6YugKHHNnXAmKzO9cBQ2tVCwLVEGDTAed0VtIBrbp8qKIbNVsA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 13:13:14 -0000 +1 - do not go into the i18n canonicalization world. Jim > -----Original Message----- > From: CBOR On Behalf Of Brian E Carpenter > Sent: Wednesday, July 18, 2018 11:58 AM > To: Sean Leonard ; Carsten Bormann = > Cc: cbor@ietf.org; Laurence Lundblade > Subject: Re: [Cbor] Representation Variants in CBOR >=20 > > If you really want a preferred serialization for CBOR, I do believe = that the > whole UTF-8 encoding thing has to be addressed. Otherwise, you treat = UTF-8 > strings exactly like byte strings, but that is not helpful to a = relying application > higher up in the stack. >=20 > We hit a very mild form of this problem while designing the GRASP = protocol, > which is encoded in CBOR. After seeking advice from the gods of > internationalization, we concluded that the only viable solution was = indeed > "treat UTF-8 strings exactly like byte strings." I would **very** = strongly suggest > keeping the many horrible issues of UTF-8 canonicalization out of the = already > complex issues of CBOR canonicalization. It's a layer 7 problem and = should be > left there. >=20 > (One result in GRASP is that if someone wants to name a GRASP = objective with > a name that includes Cyrillic "=D1=81", the "pile-of-poo" symbol and = several line > feeds, they are welcome to do so, but it's not a protocol problem.) >=20 > Regards > Brian >=20 > On 19/07/2018 01:17, Sean Leonard wrote: > > > > > >> On Jul 18, 2018, at 3:30 AM, Carsten Bormann wrote: > >> > >> > >> > >>> On Jul 18, 2018, at 01:05, Sean Leonard = wrote: > >>> > >>> > >>> I also think that major type 3 needs more work in its preferred > serialization, namely, that the UTF-8 is =E2=80=9Cwell-formed=E2=80=9D = as that term is used in > the Unicode standard. The current text of RFC7049 does not require = that the > UTF-8 be well-formed. Shortest encoding is one aspect of being = well-formed, > but not the only aspect. > >> > >> I can=E2=80=99t find =E2=80=9Cwell-formed=E2=80=9D in RFC 3629. > >> > >> CBOR does not require any specific form (e.g. normalization form) = of the > UTF-8 strings, but they do have to be UTF-8 strings. > > > > https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf > > > > D85: A Unicode code unit sequence that purports to be in a Unicode = encoding > form is called well-formed if and only if it does follow the = specification of that > Unicode encoding form. > > Summary of points: > > > > * Must be in shortest encoded form (no C0 5E stuff: identical = criteria > > as CBOR shortest encoded form, therefore not objectionable) > > * No =E2=80=9Cill-formed subsequences=E2=80=9D (example given in D86 = is <41 C2 C3 B1 > > 42>: C2 is ill-formed because it needs to have a value in the range > > 00-7F after it to correspond to a Unicode scalar value) > > * UTF-8 must only encode =E2=80=9CUnicode scalar values=E2=80=9D: = this is a little opaque but a > =E2=80=9CUnicode scalar value=E2=80=9D (D76) is any code point (0 - = 1FFFFF) *except* surrogate > code points. Therefore, well-formed UTF-8 cannot contain = U+D800-U+DFFF. > > > > See also WTF-8: > > https://simonsapin.github.io/wtf-8/ > > > > This requirement for well-formed UTF-8 is both obvious and extremely > > counterintuitive (and potentially unproductive), depending on how = you > > look at it. It is =E2=80=9Cobvious=E2=80=9D because one expects the = shortest encoded > > form, and if you encode a surrogate pair (one U+D800-U+DB00, = followed > > by one U+DC00-U+DFFF), you get 6 bytes of UTF-8 to represent a = Unicode > > scalar value in the range U+10000-U+1FFFFF, instead of 4 bytes of > > UTF-8 where the first byte starts with F0-F4. (Also: F5-FF can never > > appear in UTF-8. It would have been an interesting and perfectly = valid > > design choice to use FF as a terminal marker for an = indefinite-length > > UTF-8 string in CBOR.) > > > > But it is counterintuitive and unproductive, because many software = stacks > encode Unicode strings in UTF-16 but permit unpaired surrogates, = effectively > treating =E2=80=9CUnicode=E2=80=9D strings as arbitrary sequences of = 16-bits. These products > include JavaScript generally, Windows, Java, Mozilla (somewhat, = depends on > the boundary interface), etc. See Section 8.2 of RFC 7159. > > > > It could be a security issue to let such exceptional subsequences to > > go through, but probably the worst that will happen in practice is > > that emoji get snuck through an emoji scrubber. =F0=9F=98=82 > > > > The bigger point I guess is that to the extent that CBOR is a strict = superset of > JSON, JSON does not formally prohibit unpaired surrogates. (It = prohibits > unpaired surrogates, arguably, by requiring the JSON source text to be = in UTF- > 8, UTF-16, or UTF-32, but it explicitly enables unpaired surrogates in = escaped > form, see Section 8.2 of RFC 7159.) In fact, to the extent that JSON = is used as > the serialization format between two implementations that both use = 16-bit > =E2=80=9CUTF-16=E2=80=9D without enforcing surrogate pairing, support = for unpaired surrogates > in JSON is probably necessary for interoperability. One such reason is = because > if a naive implementation splits a Unicode string right between = surrogate pairs, > the implementation ought also to reassemble the string properly which = will > make it good again rather than delete the temporarily offending code = points. > > > > If you really want a preferred serialization for CBOR, I do believe = that the > whole UTF-8 encoding thing has to be addressed. Otherwise, you treat = UTF-8 > strings exactly like byte strings, but that is not helpful to a = relying application > higher up in the stack. > > > > Sean > > > >> > >> Consistent encoding requirements of an application may go beyond = those of > just the CBOR serialization and may include requirements on the data = in the > data items. E.g., a case-insensitive application may need to convert = strings to > lower-case. Or a Unicode application may need to normalize (in NFC, = one > might hope). Neither is the business of CBOR, which is just carrying = the text > strings. And constrained nodes usually can=E2=80=99t really solve the = LETTER BEH WITH > HAMZA ABOVE issue anyway. > >> > >>>> # If there is more than one serialization variant available that = differ in > overall length, the preferred serialization uses the shortest one. > >>>> > >>>> Now, indefinite actually is shorter for, e.g., arrays of more = than 255 > elements, so the preference for definite should be explicitly *higher = priority* > than the overall length. On the other hand, the preference for = definite is > *weaker* =E2=80=94 there are many good reasons to go to indefinite = length in > particular for arrays and maps (otherwise we wouldn=E2=80=99t have = that variant!). > >>> > >>> I do not know if being in definite form is desirable for this = =E2=80=9Cpreferred > serialization=E2=80=9D business, for reasons that Carsten mentions. = Forcing maps and > arrays to be in definite form requires that the number of items be = known in > advance. (This is better than ASN.1, which requires pre-serializing = all of the > elements, but is still not the best.) Indefinite form has notable = advantages, > including having an encoder be able to stream out content infinitely > (think=E2=80=A6indefinite media stream, indefinite sensor stream, = etc.). > >> > >> I agree that the =E2=80=9Cpreferredness=E2=80=9D is weaker here. = But in many cases array > and map sizes are known, and in that case (i.e., absence of a good = reason to go > non-preferred) definite is still preferred. > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > > > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sun Jul 22 07:07:15 2018 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 8208A130F2C for ; Sun, 22 Jul 2018 07:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dYOwbD-tktq3 for ; Sun, 22 Jul 2018 07:07:11 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4B3130E1D for ; Sun, 22 Jul 2018 07:07:11 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F8242750D for ; Sun, 22 Jul 2018 10:07:09 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Sun, 22 Jul 2018 07:07:08 -0700 References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> To: cbor@ietf.org In-Reply-To: <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> Message-Id: <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 14:07:15 -0000 > On Jul 18, 2018, at 7:07 PM, Carsten Bormann wrote: >=20 > On Jul 18, 2018, at 09:17, Sean Leonard wrote: >>=20 >> https://www.unicode.org/versions/Unicode11.0.0/ch03.pdf >=20 > Ah. That is not relevant for RFC 7049. UTF-8 is defined in RFC 3629. >=20 > I believe RFC 3629 is very clear about what is UTF-8 and what is not, = without needing to resort to gradations like well-formed but invalid = (and most of what could be considered a bit on the side of weasel-words = are caused by the abortive idea of carrying a BOM in UTF-8). I do not think anybody is considering putting BOMs in tstr (CBOR UTF-8 = text strings). Also, none of this has to do with Unicode = internationalization/canonicalization/normalization. That is a totally = different subject. Recourse to RFC 3629 confirms the points that I raised. Here is text = from RFC 3629: o The octet values C0, C1, F5 to FF never appear. o The byte-value lexicographic sorting order of UTF-8 strings is the same as if ordered by character numbers. Of course this is of limited interest since a sort order based on character numbers is almost never culturally valid. The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. When encoding in UTF-8 from UTF-16 data, it is necessary to first decode the UTF-16 data to obtain character numbers, which are then encoded in UTF-8 as described above. This contrasts with CESU-8 [...] Implementations of the decoding algorithm above MUST protect against decoding invalid sequences. For instance, a naive implementation may decode the overlong UTF-8 sequence C0 80 into the character U+0000, or the surrogate pair ED A1 8C ED BE B4 into U+233B4. Decoding invalid sequences may have security consequences or cause other problems. See Security Considerations (Section 10) below. NOTE -- The authoritative definition of UTF-8 is in [UNICODE]. This grammar is believed to describe the same thing Unicode describes, but does not claim to be authoritative. Implementors are urged to rely on the authoritative source, rather than on this ABNF. Security Considerations Implementers of UTF-8 need to consider the security aspects of how they handle illegal UTF-8 sequences. It is conceivable that in some circumstances an attacker would be able to exploit an incautious UTF-8 parser by sending it an octet sequence that is not permitted by the UTF-8 syntax. A particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters. For example, a parser might prohibit the NUL character when encoded as the single-octet sequence 00, but erroneously allow the illegal two-octet sequence C0 80 and interpret it as a NUL character. Another example might be a parser which prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the illegal octet sequence 2F C0 AE 2E 2F. This last exploit has actually been used in a widespread virus attacking Web servers in 2001; thus, the security threat is very real. Another security issue occurs when encoding to UTF-8: the ISO/IEC 10646 description of UTF-8 allows encoding character numbers up to U+7FFFFFFF, yielding sequences of up to 6 bytes. There is therefore a risk of buffer overflow if the range of character numbers is not explicitly limited to U+10FFFF or if buffer sizing doesn't take into account the possibility of 5- and 6-byte sequences. So RFC 3629 is indeed clear, and it incorporates all of the points in = the Unicode standard, which have not actually changed between the = publication of RFC 3629 (which references Unicode 4.0 normatively) and = the current Unicode 11.0. The implications for CBOR are clear: #1: To the extent that CBOR needs to determine whether two tstrs are = equal (e.g., for map key comparison), UTF-8 needs to be decoded and = checked to Unicode code points. A tstr that contains and a tstr = that contains <00> encodes the same code point: U+0000. Therefore, there = is a collision. Furthermore, is illegal (=E2=80=9Cill-formed=E2=80= =9D) anyway. Replacing with U+FFFD would be bad. A = naive memcmp will miss this. The CBOR decoder can have several possible behaviors in the + = <00> case. It could drop one key/value pair. It could drop the other = key/value pair. It could signal a fatal error. But it really should not = treat the two strings as =E2=80=9Cdifferent keys=E2=80=9D (which it = would if they were bstrs), nor should it try to rewrite as = U+FFFD or undefined or similar. The same analysis goes for and . Both represent =E2=80=9C=3D= =E2=80=9D. They are different bstrs, but the same tstrs. A naive = bit-for-bit comparison will let both through as unique keys, which is an = exploitable problem. Rejecting both as ill-formed UTF-8 is okay; = recognizing both as equivalent to =E2=80=9C=3D=E2=80=9D is also okay (to = the extent that they then are seen as duplicate keys in the map). Even = recognizing both as =E2=80=9C=E2=80=9D (dropping everything after the = first ill-formed subsequence) or =E2=80=9CU+FFFD=3D=E2=80=9C (replacing) = would be okay since they would still be recognized as duplicates. But = letting both through as unique keys would be bad. Really the analysis is the same for a CBOR map that contains uint keys = that are encoded as <08> and <00 08>. The difference is that <00 08> is = legal in RFC 7049 CBOR, whereas and are not legal in = UTF-8. #2: I think that any =E2=80=9Cpreferred serialization=E2=80=9D needs to = point out that UTF-8 needs to be checked. But a generic decoder that = checks for equality of map keys also needs to check UTF-8. I would argue = that all generic CBOR decoders SHOULD check UTF-8. The operation is = cheap (and actually can be handled in parallel on a multi-threaded CPU). = I do not see a performance issue on resource-constrained devices, since = I thought that resource-constrained devices won=E2=80=99t be receiving = tstrs that often anyway; if they do, ASCII tstrs are the most likely, so = the code paths for > U+007F won=E2=80=99t be exercised all that often. #3: Read the WTF-8 document for dealing with unpaired surrogates. The = way I see it is that the industry kind of does a wink and a nod in this = regard (at least, many UTF-8 decode implementations do the = wink-and-nod). If an unpaired surrogate is encountered (a U+D800-U+DFFF = taken in isolation, not talking about the CESU-8 6-byte case vs. proper = UTF-8 4-byte case), the robust way to handle it is to let it pass. The = reason is because from CBOR=E2=80=99s perspective, it does not impact = the security of the equality operation on map keys, because there is no = alternative serialization than that one 3-byte sequence. It is probably = best to say nothing about that topic (WTF-8) in any CBOR documents, as = long as we go into it with eyes open. #4: I see the equality issue in programming terms: the CBOR decoder = ought to say: if (key1 =3D=3D key2) { /* deal with collision */ } else { /* add (key2, value2) to in-memory map */ }, where the =3D=3D operator is overloaded to deal with: 1) integers (includes CBOR tags), 2) floats, 3) binary strings (memcmp), 4) UTF-8 strings. With 2) floats, you call the IEEE 754-compliant comparison instruction = on the CPU. With 4) UTF-8 strings, you call the =E2=80=9Cutf8check=E2=80=9D= and =E2=80=9Cutf8cmp=E2=80=9D functions, however your = platform/OS/library implements that. (Note that =E2=80=9Cutf8cmp=E2=80=9D = =3D=3D=3D memcmp only after you know =E2=80=9Cutf8check=E2=80=9D = succeeds. This is also why unpaired surrogates are okay, since if the = local utf8check lets unpaired surrogates go through, that code point = can=E2=80=99t possibly be rewritten to anything else anyway.) Hope this helps, Sean >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Sun Jul 22 10:15:47 2018 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 5108F130DE9; Sun, 22 Jul 2018 10:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BReNJFWxxM_D; Sun, 22 Jul 2018 10:15:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ACB130DD3; Sun, 22 Jul 2018 10:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6MHFcNh009257; Sun, 22 Jul 2018 19:15:38 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41YWV20KnxzDX6N; Sun, 22 Jul 2018 19:15:38 +0200 (CEST) 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: <20180722161656.5B12EB813D1@rfc-editor.org> Date: Sun, 22 Jul 2018 19:15:37 +0200 Cc: Paul Hoffman , The IESG , lambdav@orange.fr, cbor@ietf.org X-Mao-Original-Outgoing-Id: 553972535.4616489-c62d5e2f13fbbd6cadea53b39557c1a9 Content-Transfer-Encoding: quoted-printable Message-Id: <9EA0357A-7B19-4FA9-B039-9D30AE53BD2E@tzi.org> References: <20180722161656.5B12EB813D1@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (5434) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 17:15:45 -0000 Hi David, thank you for this report! It appears =E2=80=9CUBJSON=E2=80=9D is now a specification completely = different from what it was in 2013, sharing only the name. The peril of = referencing a website for a specification. If you have more information = about what happened to =E2=80=9CUBJSON" in the last five years, this = could be quite interesting. I would propose classifying this as =E2=80=9Chold for document = update=E2=80=9D, with a view of removing UBJSON from the illustrative = appendix: the use will create confusion and the example is not at all = necessary for making use of CBOR. (The updated text of RFC 7049 is = being actively worked on by the CBOR WG, draft at = https://github.com/cbor-wg/CBORbis =E2=80=94 comments on this document = are very welcome!) (As a separate observation, I will note that the Experimental RFC 8060 = references UBJSON without specifying whether the old or the new = specification is intended.) Gr=C3=BC=C3=9Fe, Carsten > On Jul 22, 2018, at 18:16, 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: > http://www.rfc-editor.org/errata/eid5434 >=20 > -------------------------------------- > Type: Technical > Reported by: LAMBERT David >=20 > Section: E.6 >=20 > Original Text > ------------- > | | | = | > | UBJSON | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 = | > | | 42 03 | 42 03 45 = | > | | | = | >=20 >=20 > Corrected Text > -------------- > | | | = | > | UBJSON | 5B 23 55 02 55 01 5B 23 | 5B 55 01 5B 55 02 55 03 = | > | | 55 02 55 02 55 03 | 5D 5D = | > | | | = | >=20 >=20 > Notes > ----- > According to UBJSON type specification available at > http://ubjson.org/type-reference/ arrays are encoded with = square-brackets '[' and ']', or with '[' followed by '#' to specify the = element count. >=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 From nobody Sun Jul 22 12:42:22 2018 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 E5118130E2D for ; Sun, 22 Jul 2018 12:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nU52Xrgrfi6 for ; Sun, 22 Jul 2018 12:42:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB598130DF0 for ; Sun, 22 Jul 2018 12:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6MJgFMV027035; Sun, 22 Jul 2018 21:42:15 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41YZlC3jzrzDX79; Sun, 22 Jul 2018 21:42:15 +0200 (CEST) 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: <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> Date: Sun, 22 Jul 2018 21:42:14 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 553981332.912128-b55602c3a83ad6153b24a333b7ad4ff8 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 19:42:21 -0000 On Jul 22, 2018, at 16:07, Sean Leonard wrote: >=20 > The implications for CBOR are clear: Not to me. I don=E2=80=99t agree that any of these is an implication. Most of this actually would be an unmotivated deviation from the = established existing practice; we don=E2=80=99t do that when moving a = Proposed Standard to Internet Standard. Specifically, the purpose of the reference to RFC 3629 is to have a = stable definition of UTF-8. There is no need to repeat any of this material in the definition of = CBOR. It is up to an application whether checking of the UTF-8 encoding rules = actually needs to be performed on incoming data or the UTF-8 strings can = just be shipped around unchanged. If the application specified strict = processing, then UTF-8 has to be checked (section 3.10). That checking = has to follow RFC 3629, not any rules we make up in the CBOR = specification. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 22 14:01:18 2018 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 DA75E130DF9 for ; Sun, 22 Jul 2018 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dVFpGOcgp0n for ; Sun, 22 Jul 2018 14:01:14 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 EC7EA130DCE for ; Sun, 22 Jul 2018 14:01:13 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id b1-v6so7337446pls.5 for ; Sun, 22 Jul 2018 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Iz+zslK5nyUYnuZilC8YdPsQ3ENkuzTxzFD16Qfl/II=; b=Hrnh5XdfqEnSiZBprZtWV0BplZYH0QLnt1vNfyQzLQdRVLnIPBTam8BqqcMyedcI5z ocEvloby5qc5ZmFBRKYA7LEg/gjBeJYlNNv1L3GdEFEpNE98Dj9gLg0omUmbn8HWN8zw S+Z9kHncZK6zaI7xKT4mUKGx1BS0Q3DAFFhBksAsWozwYHL0pzjGDM4DRq0oV3PNyYDD bDQIpnTdU9szQIBMw91G1DvBYm7RgF51gDwS2yCVIGwEVU//qEl2TYhIABpTBoe4/U4Z 7GSm5U33Higl9j1O91Qje9p+xhyJJVT6hml+/H0SGnPz67KrgIFjaY5waxUjht1snUTj fAHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Iz+zslK5nyUYnuZilC8YdPsQ3ENkuzTxzFD16Qfl/II=; b=iNJglCClIyyDgQpz9CjNPl/0MUwvU9RqGu9822zA4fBp/4UB0JQ1ZK9Uy6eGSO2+Ki AmVMR3Ld9lG3brnM2IRj9unYr1KOHAKNXgU1a0Hm9ao6tNfoSrs49b05Ew46AswWi2km nrPZPaByLS1eBh+X+FsRnWaKe+y7weCY6RwqWPJ8iB7xIT1q/3D5bcb4sWxnR9+bArhV 7Peyfk5KFognxyiDNm3Jk8aP77KfpvenkuaVXt80PlRA2ytiG6sqecUuDCmkWQe8Fub4 DhE/qFiTNP3yqsWH4R3R2Zj2313emXDzXlwFo4LzG0meYjdNdZmUlxt/xVxYA4RNyXYn 8Sdw== X-Gm-Message-State: AOUpUlH3vn2ubVgu8187pY6rxePHzz/GIouRie+j6LWQHSszrtjujAx3 1Q4eiCIUsx/PVBRPRXn1bnqmOVtl X-Google-Smtp-Source: AAOMgpcDaqZ5QY0+nEj9TNbRrL8XeZAQ3nKtC6/n1+XWBdb0pea6D0iqFBY4+jaGDBCU0Kg3Htx6Sg== X-Received: by 2002:a17:902:ab90:: with SMTP id f16-v6mr10613667plr.182.1532293273156; Sun, 22 Jul 2018 14:01:13 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 203-v6sm11480227pgb.14.2018.07.22.14.01.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 14:01:12 -0700 (PDT) To: cbor@ietf.org References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> From: Brian E Carpenter Message-ID: Date: Mon, 23 Jul 2018 09:01:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 21:01:17 -0000 On 23/07/2018 07:42, Carsten Bormann wrote: > On Jul 22, 2018, at 16:07, Sean Leonard wrote: >> >> The implications for CBOR are clear: >=20 > Not to me. I don=E2=80=99t agree that any of these is an implication. I agree. It's matter of choice. If we choose to define equality of two UTF-8 strings as bitwise equality that's perfectly consistent. An *application* of CBOR might wish to do otherwise but that's before encoding or after decoding. I do agree that map keys need very clear thinking, but if we *define* key equality for UTF-8 keys as bitwise equality, we bump the problem to the application, which is where it should be IMHO. Specifically: > resource-constrained devices won=E2=80=99t be receiving tstrs that ofte= n anyway; if they do, ASCII tstrs are the most likely, so the code paths = for > U+007F won=E2=80=99t be exercised all that often. That would increase the footprint of the decoder anyway. Memory counts in constrained nodes, as well as the code path. In the text of 7049bis, "Specifying Keys for Maps" probably needs to clarify that UTF-8 keys are compared bitwise. Somewhere we need to state that UTF-8 normalization is out of scope for encoders/decoders. (I realise Sean won't agree, but at least we need to be clear.) Brian >=20 > Most of this actually would be an unmotivated deviation from the establ= ished existing practice; we don=E2=80=99t do that when moving a Proposed = Standard to Internet Standard. >=20 > Specifically, the purpose of the reference to RFC 3629 is to have a sta= ble definition of UTF-8. > There is no need to repeat any of this material in the definition of CB= OR. >=20 > It is up to an application whether checking of the UTF-8 encoding rules= actually needs to be performed on incoming data or the UTF-8 strings can= just be shipped around unchanged. If the application specified strict p= rocessing, then UTF-8 has to be checked (section 3.10). That checking ha= s to follow RFC 3629, not any rules we make up in the CBOR specification.= >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Sun Jul 22 18:11:09 2018 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 E1C08130DE5 for ; Sun, 22 Jul 2018 18:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 N9BPsIPMWVNx for ; Sun, 22 Jul 2018 18:11:05 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B94124BE5 for ; Sun, 22 Jul 2018 18:11:05 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 371052754F; Sun, 22 Jul 2018 21:11:02 -0400 (EDT) To: Carsten Bormann Cc: cbor@ietf.org, Thiago Macieira , Doug Ewell References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> From: Sean Leonard Message-ID: <66628646-c25f-b903-8a54-67bc54f9c0aa@seantek.com> Date: Sun, 22 Jul 2018 18:09:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Sent-To: Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 01:11:08 -0000 On 7/22/2018 12:42 PM, Carsten Bormann wrote: > On Jul 22, 2018, at 16:07, Sean Leonard wrote: >> The implications for CBOR are clear: > Not to me. I don=E2=80=99t agree that any of these is an implication. > > Most of this actually would be an unmotivated deviation from the establ= ished existing practice; we don=E2=80=99t do that when moving a Proposed = Standard to Internet Standard. > > Specifically, the purpose of the reference to RFC 3629 is to have a sta= ble definition of UTF-8. > There is no need to repeat any of this material in the definition of CB= OR. > > It is up to an application whether checking of the UTF-8 encoding rules= actually needs to be performed on incoming data or the UTF-8 strings can= just be shipped around unchanged. If the application specified strict p= rocessing, then UTF-8 has to be checked (section 3.10). That checking ha= s to follow RFC 3629, not any rules we make up in the CBOR specification. Sorry but I am rather confused by this response. Nowhere in my e-mail=20 did I state or suggest a change to RFC 7049. The texts of both RFC 3629=20 and RFC 7049 are fine as they are. In fact, I directly quoted the text=20 of RFC 3629. That is also why I said: "*To the extent* that CBOR needs=20 to determine whether two tstrs are equal (e.g., for map key=20 comparison)", and, "a generic decoder *that checks for equality of map=20 keys* also needs to check UTF-8". I readily acknowledge that there are=20 CBOR decoders (for example, small streaming decoders) whose design=20 requirements preclude checking for equality of map keys, and therefore,=20 that do not operate in Strict Mode. I did not specifically distinguish Strict Mode by name, however, so=20 sorry about not calling that out. I acknowledge that I also made a stronger statement: "I would argue that=20 all generic CBOR decoders SHOULD check UTF-8." I still stand by this=20 statement, but did not, and do not, propose any changes to the RFC 7049=20 text. RFC 3629 makes a normative statement: "Implementations of the decoding=20 algorithm above MUST protect against decoding invalid sequences." That=20 is actually a change from RFC 2279, and is noted as such in Section 12=20 RFC 3629. There is a legitimate question as to whether "UTF-8 decoding" is=20 happening at all when dealing with CBOR. To the extent that CBOR is=20 ingested by a decoder and tstrs are converted to 16-bit code units,=20 i.e., UTF-16 (as, for example, in many JavaScript engines and APIs,=20 including but not limited to Windows and Apple/macOS/iOS), the=20 UTF-8-to-UTF-16 decoding algorithm is triggered. Similarly, if the=20 source representation is in 16-bit code units (UTF-16 or something like=20 it), the UTF-16-to-UTF-8 encoding algorithm will always be triggered=20 when doing CBOR encoding. A properly implemented UTF-16-to-UTF-8=20 encoding algorithm will never emit overlong encodings or out-of-range=20 bytes (C0, C1, F5-FF). However, there are other situations when the tstr content is not changed=20 when CBOR is decoded (i.e., remains in 8-bit units, ostensibly UTF-8).=20 It is possible that the decoding algorithm is therefore not triggered in=20 those implementations. Alarm bells always sound in my head when data crosses a security=20 boundary. CBOR passing between two mutually trusted components is not a=20 security boundary. Loading CBOR from disk into memory is *probably* not=20 a security boundary, but it depends. However, when stuff is sent and=20 received across the Internet between different vendor implementations,=20 there is an obvious security boundary. The stuff purporting to be=20 "UTF-8" therefore really ought to be checked in most network-connected=20 circumstances. It is important that it be checked once. It need not be=20 checked repeatedly, but the problem is when the implementation in one=20 layer thinks that the checking will be done at a different layer, and=20 vice versa, resulting in no checks. There is a real danger that a CBOR decoder, which has no need to convert=20 from UTF-8 to UTF-16 in-memory, will just slap a label on the chunk of=20 data as "UTF-8 =3D good" and pass it along.=E2=80=A0 What happens, then, = when that=20 in-memory CBOR needs to be serialized back out? The encoder then needs=20 to check whether the UTF-8 really *is* good, especially if it's=20 operating in "Strict Mode" (actually defined by RFC 7049) or some=20 "preferred serialization" (the subject of this thread). So, Thiago's comment on July 18: "Sure, the *encoder* should strive to=20 not send invalid UTF-8 anymore than duplicated keys in a map." is=20 actually correct. But is it the responsibility of the encoder to check=20 UTF-8 when the other parts of the software stack have already=20 represented that the UTF-8 is good? How many implementers can raise=20 their hands today and say, "yes, my CBOR implementation checks that the=20 UTF-8 string in memory really is well-formed UTF-8 before it is encoded=20 on the wire?" None of this stuff is new. See Section 3 "Non-Visual Security Issues" of=20 Unicode Technical Report #36, Unicode Security Considerations.=20 In particular: Sections 3.1,=20 3.5, 3.6, and 3.7. Ignore the sections that talk about normalization=20 because they are not relevant for this conversation (nothing in this=20 conversation has to do with NFC or whatever). I still maintain that no text from RFC 7049 needs to be changed in this=20 regard. But, proposed text about "bitwise comparison" and the like=20 should not be added either. Regards, Sean =E2=80=A0Malicious UTF-8 (overlong encoding, for example) is not always=20 exploitable. If the malicious data is compared bitwise against a fixed=20 trusted string, it will fail since the trusted string will be=20 well-formed but the malicious string is ill-formed. From nobody Sun Jul 22 18:25:18 2018 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 1D266130E09 for ; Sun, 22 Jul 2018 18:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 QDX3YxLzbyto for ; Sun, 22 Jul 2018 18:25:15 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB24E130DD2 for ; Sun, 22 Jul 2018 18:25:15 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CD4C27517 for ; Sun, 22 Jul 2018 21:25:14 -0400 (EDT) To: cbor@ietf.org From: Sean Leonard Message-ID: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> Date: Sun, 22 Jul 2018 18:23:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 01:25:17 -0000 Just wanted to throw this out there: What do current CBOR implementations do when comparing two floats (major type 7, values 25, 26, 27) for equality, specifically in the case of comparing keys for maps? Are there any implementations that will compare any float with a float of a different size (e.g., binary32 and binary64) and return equal? Are there any implementations that will compare any float with an int (major types 0 or 1) and return equal? Are there any implementations that will compare any float containing some NaN, with any other float containing some NaN, and return equal? I really would like to know what implementations do (or, at least, what they are programmed to do), not discuss how it should be. Regards, Sean From nobody Sun Jul 22 21:20:01 2018 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 0F3BB130E2C for ; Sun, 22 Jul 2018 21:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZNx41peZoOpP for ; Sun, 22 Jul 2018 21:19:58 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 EF9E6130DC6 for ; Sun, 22 Jul 2018 21:19:57 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2018 21:19:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,392,1526367600"; d="scan'208";a="58624458" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga007.jf.intel.com with ESMTP; 22 Jul 2018 21:19:57 -0700 Received: from tjmaciei-mobl1.localnet (10.254.99.150) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 22 Jul 2018 21:19:56 -0700 From: Thiago Macieira To: CC: Sean Leonard Date: Sun, 22 Jul 2018 21:19:56 -0700 Message-ID: <2403787.fdFKWUfMDL@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.99.150] Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 04:20:00 -0000 On Sunday, 22 July 2018 18:23:23 PDT Sean Leonard wrote: > Just wanted to throw this out there: > > What do current CBOR implementations do when comparing two floats (major > type 7, values 25, 26, 27) for equality, specifically in the case of > comparing keys for maps? Using floating point as keys for maps is a bad practice in almost every programming language. I think the CBOR specification should be very clear that CBOR maps should prefer to use integers and strings for keys, with tagged (extended) types as a distant second. Other keys are permitted, of course, but discouraged. > Are there any implementations that will compare any float with a float > of a different size (e.g., binary32 and binary64) and return equal? Yes. My implementation in QCborValue decodes any and all floating point to a an internal storage of double. So the following map ends up "invalid" due to duplicated keys: { 0.0: "one", 0.0f: "two" } > Are there any implementations that will compare any float containing > some NaN, with any other float containing some NaN, and return equal? Yes, QCborValue compares the bit pattern for the floating point, which means two NaN compare equal, instead of comparing different as IEEE dictates. It will also perform sorting according to the big-endian bit pattern, not according to the number stored, so 1.0 < -1.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 23 08:25:00 2018 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 D8672130F39 for ; Mon, 23 Jul 2018 08:24:49 -0700 (PDT) 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, 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=mozilla.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 TLcxyRDUzo0G for ; Mon, 23 Jul 2018 08:24:46 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 53FC5130ED3 for ; Mon, 23 Jul 2018 08:24:46 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id w126-v6so1809958oie.7 for ; Mon, 23 Jul 2018 08:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cI8djI4og/vsB9g6g3dn1oB+9TsGq/HS5e7nKhW7kFU=; b=CKv9N9uj5XxRh/sPF5voe0JrUy9X+jl5vpbdnCKaBuBpE9Y2xWlVJTPNaCWN9HdtZU lWkAmVqrqG/oZdtFAJXo1i4iZ7TTZJf9op9ntlyzCtcKrWUOzkOKnNixx/JEg4GgcvM5 QxMgSsLEZIjm5R+FBo7dzDHcmx1UgxS2pDMgU= 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=cI8djI4og/vsB9g6g3dn1oB+9TsGq/HS5e7nKhW7kFU=; b=HW+pdEuyV+BMXiiBoidg+tcy24hsgJTuhLGNhdF+LCyydOYVHcNEYRsHxdhFiwakXX w0TEEGmUmv3SysgTbH2nneMVYYaBBFPyFrdDtFkfXrG7PzJh2UWD7WrAaj6IAGWxBNwo Md98YuU/EFAcR+/03dPwl5Ix5OOKiMY4zzKvkNTuITBf/qFeGiOzrHp3DmWEoeoLQQGf Wi4xDpRFlpItSSz7hQ4f3MIu7RKrjLvBW6WI7AFFc3+Iup1jJf2aY7rjwa7MaoVbrJXr j1bjhlcfEPMMJdMpEkP4yENNi7rrVLWDOBXuxah3JkZor2sBuz08vCRlWIl2w4KhnAFx nJog== X-Gm-Message-State: AOUpUlGaKhOtsh1AHUKlINAgje+iRfGFagzpKUNNKhbowljYc5+MPN96 SAuPp5EUWWvSqf0tJwPOcigZZg== X-Google-Smtp-Source: AAOMgpfYmjIMiVn0Jwk17Ers70/NP9aZHT6MfqeaSKfo+0zUXzH7Kfp3n/okMgoz/x8XCvHdtXXjuQ== X-Received: by 2002:aca:6ac8:: with SMTP id f191-v6mr8462505oic.223.1532359485450; Mon, 23 Jul 2018 08:24:45 -0700 (PDT) Received: from [10.6.16.209] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id 10-v6sm6515532oip.29.2018.07.23.08.24.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 08:24:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Hildebrand In-Reply-To: <2403787.fdFKWUfMDL@tjmaciei-mobl1> Date: Mon, 23 Jul 2018 09:24:43 -0600 Cc: cbor@ietf.org, Sean Leonard Content-Transfer-Encoding: quoted-printable Message-Id: <2DA65043-2E43-4FEA-9B0F-0EBFCAA143DB@mozilla.com> References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> <2403787.fdFKWUfMDL@tjmaciei-mobl1> To: Thiago Macieira X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:24:55 -0000 > On Jul 22, 2018, at 10:19 PM, Thiago Macieira = wrote: >=20 > Using floating point as keys for maps is a bad practice in almost = every=20 > programming language. I think the CBOR specification should be very = clear that=20 > CBOR maps should prefer to use integers and strings for keys, with = tagged=20 > (extended) types as a distant second. Other keys are permitted, of = course, but=20 > discouraged. Agree. >> Are there any implementations that will compare any float with a = float >> of a different size (e.g., binary32 and binary64) and return equal? >=20 > Yes. My implementation in QCborValue decodes any and all floating = point to a=20 > an internal storage of double. So the following map ends up "invalid" = due to=20 > duplicated keys: >=20 > { 0.0: "one", 0.0f: "two=E2=80=9D } Mine will compare the generated bytes for each key, same as for = ordering. >> Are there any implementations that will compare any float containing >> some NaN, with any other float containing some NaN, and return equal? >=20 > Yes, QCborValue compares the bit pattern for the floating point, which = means=20 > two NaN compare equal, instead of comparing different as IEEE = dictates. It=20 > will also perform sorting according to the big-endian bit pattern, not=20= > according to the number stored, so 1.0 < -1.0. Same here. =E2=80=94=20 Joe Hildebrand From nobody Mon Jul 23 09:08:06 2018 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 DF06A130EB7 for ; Mon, 23 Jul 2018 09:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Z2a6iTbLCZdA for ; Mon, 23 Jul 2018 09:08:03 -0700 (PDT) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECF3130EAC for ; Mon, 23 Jul 2018 09:08:02 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6235D274EC; Mon, 23 Jul 2018 12:08:01 -0400 (EDT) To: Thiago Macieira , cbor@ietf.org References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> <2403787.fdFKWUfMDL@tjmaciei-mobl1> From: Sean Leonard Message-ID: <610d63b2-7401-6c30-ec47-f4c1f827de08@seantek.com> Date: Mon, 23 Jul 2018 09:06:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2403787.fdFKWUfMDL@tjmaciei-mobl1> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sent-To: Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:08:05 -0000 On 7/22/2018 9:19 PM, Thiago Macieira wrote: > On Sunday, 22 July 2018 18:23:23 PDT Sean Leonard wrote: >> Just wanted to throw this out there: >> >> What do current CBOR implementations do when comparing two floats (major >> type 7, values 25, 26, 27) for equality, specifically in the case of >> comparing keys for maps? > Using floating point as keys for maps is a bad practice in almost every > programming language. I think the CBOR specification should be very clear that > CBOR maps should prefer to use integers and strings for keys, with tagged > (extended) types as a distant second. Other keys are permitted, of course, but > discouraged. Not taking a moral stance on it at this time. :-) I can think of perfectly valid applications (scientific, sensor measurements), but do not think they need to be delved into yet. Better to get the data first. How about the question of: can a float ever compare to an int (positive or negative), and return equal, in your implementation? I read , and my guess is "no", since the two CBOR items have to have the same major type for further comparisons to proceed. Sean From nobody Mon Jul 23 10:09:55 2018 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 AC4F3130E22 for ; Mon, 23 Jul 2018 10:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 V5Zcwd_p7mbk for ; Mon, 23 Jul 2018 10:09:51 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361BD130DEA for ; Mon, 23 Jul 2018 10:09:51 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 23 Jul 2018 10:06:14 -0700 From: Jim Schaad To: 'Joe Hildebrand' , 'Thiago Macieira' CC: , 'Sean Leonard' References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> <2403787.fdFKWUfMDL@tjmaciei-mobl1> <2DA65043-2E43-4FEA-9B0F-0EBFCAA143DB@mozilla.com> In-Reply-To: <2DA65043-2E43-4FEA-9B0F-0EBFCAA143DB@mozilla.com> Date: Mon, 23 Jul 2018 10:09:42 -0700 Message-ID: <019701d422a7$f4c3ea30$de4bbe90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIGcuaa1m+N3ebBnxaZdJ4rY/1NZQHmIOQ7AccJi/SkGwCY8A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 17:09:54 -0000 > -----Original Message----- > From: CBOR On Behalf Of Joe Hildebrand > Sent: Monday, July 23, 2018 8:25 AM > To: Thiago Macieira > Cc: cbor@ietf.org; Sean Leonard > Subject: Re: [Cbor] Survey of floating-point >=20 > > On Jul 22, 2018, at 10:19 PM, Thiago Macieira = > wrote: > > > > Using floating point as keys for maps is a bad practice in almost > > every programming language. I think the CBOR specification should be > > very clear that CBOR maps should prefer to use integers and strings > > for keys, with tagged > > (extended) types as a distant second. Other keys are permitted, of > > course, but discouraged. >=20 > Agree. >=20 > >> Are there any implementations that will compare any float with a > >> float of a different size (e.g., binary32 and binary64) and return = equal? > > > > Yes. My implementation in QCborValue decodes any and all floating > > point to a an internal storage of double. So the following map ends = up > > "invalid" due to duplicated keys: > > > > { 0.0: "one", 0.0f: "two=E2=80=9D } >=20 > Mine will compare the generated bytes for each key, same as for = ordering. The version that I use will compare the CBOR Type before comparing = values - so I get the same answer as Joe. Jim >=20 > >> Are there any implementations that will compare any float = containing > >> some NaN, with any other float containing some NaN, and return = equal? > > > > Yes, QCborValue compares the bit pattern for the floating point, = which > > means two NaN compare equal, instead of comparing different as IEEE > > dictates. It will also perform sorting according to the big-endian = bit > > pattern, not according to the number stored, so 1.0 < -1.0. >=20 > Same here. >=20 > =E2=80=94 > Joe Hildebrand >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon Jul 23 10:10:50 2018 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 AC2FE130DEA for ; Mon, 23 Jul 2018 10:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 2hKxUzmJPhc6 for ; Mon, 23 Jul 2018 10:10:45 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 C9641126F72 for ; Mon, 23 Jul 2018 10:10:45 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 10:10:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,393,1526367600"; d="scan'208";a="247639890" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga005.fm.intel.com with ESMTP; 23 Jul 2018 10:10:45 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.60) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Jul 2018 10:10:45 -0700 From: Thiago Macieira To: Sean Leonard CC: Date: Mon, 23 Jul 2018 10:10:44 -0700 Message-ID: <2689443.GGYIV70MrV@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <610d63b2-7401-6c30-ec47-f4c1f827de08@seantek.com> References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> <2403787.fdFKWUfMDL@tjmaciei-mobl1> <610d63b2-7401-6c30-ec47-f4c1f827de08@seantek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.60] Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 17:10:49 -0000 On Monday, 23 July 2018 09:06:10 PDT Sean Leonard wrote: > How about the question of: can a float ever compare to an int (positive > or negative), and return equal, in your implementation? > > I read > lue.cpp?h=dev>, and my guess is "no", since the two CBOR items have to have > the same major type for further comparisons to proceed. Correct, that's how it's implemented. However, the front-end class does allow toInteger() on a double and toDouble() on an integer. qint64 toInteger(qint64 defaultValue = 0) const { return isInteger() ? value_helper() : isDouble() ? qint64(fp_helper()) : defaultValue; } double toDouble(double defaultValue = 0) const { return isDouble() ? fp_helper() : isInteger() ? double(value_helper()) : defaultValue; } So I can still change this (either or both). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Mon Jul 23 11:14:48 2018 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 5A396130DE9 for ; Mon, 23 Jul 2018 11:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPe9ReSaJv09 for ; Mon, 23 Jul 2018 11:14:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396B1130DD3 for ; Mon, 23 Jul 2018 11:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6NIEcV5027351; Mon, 23 Jul 2018 20:14:39 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Z8lf4S07zDXJ9; Mon, 23 Jul 2018 20:14:38 +0200 (CEST) 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: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> Date: Mon, 23 Jul 2018 20:14:37 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 554062475.921769-4c08fe49a41f3a7138b7e6541ca17805 Content-Transfer-Encoding: quoted-printable Message-Id: <82868257-2D3D-468D-BCB8-9BE33132A219@tzi.org> References: <245af61d-2990-ead2-1841-40f8befbf677@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Survey of floating-point X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:14:46 -0000 > On Jul 23, 2018, at 03:23, Sean Leonard wrote: >=20 > Just wanted to throw this out there: >=20 > What do current CBOR implementations do when comparing two floats = (major type 7, values 25, 26, 27) for equality, specifically in the case = of comparing keys for maps? CBOR-Ruby does not compare any data items. (CBOR-canonical for Ruby = does order them, according to the recommendations in Section 3.9 of RFC = 7049, i.e. in the canonically encoded form.) When Ruby-cbor builds maps, it uses the infrastructure of Ruby for that = (class Hash, which is based on =E2=80=9C.hash=E2=80=9D hashing and = =E2=80=9C.eql?=E2=80=9D comparison). Map building occurs at the data = model level, so representation invariants are not visible any more. The peculiarities of Ruby floating point support mean that 0 and 0.0 are = valid as two different map keys, while 0.0 and -0.0 are not (same = =E2=80=9C.hash=E2=80=9D). One could consider that to be a bug (in Ruby, that is). >=20 > Are there any implementations that will compare any float with a float = of a different size (e.g., binary32 and binary64) and return equal? All reasonable ones will (representation variants do not enter at the = data model level). > Are there any implementations that will compare any float with an int = (major types 0 or 1) and return equal? Implementations for languages with a limited numeric type system may; = this depends on whether a map type is available that allows for keys at = the data model level. > Are there any implementations that will compare any float containing = some NaN, with any other float containing some NaN, and return equal? For the purpose of map keys, it is not normal comparison that counts, so = you get the following anomaly: >> {0 =3D> "0", 0.0 =3D> "0.0", -0.0 =3D> "-0.0", Float::NAN =3D> "NaN", = -Float::NAN =3D> "NaN", Float::NAN =3D> "NaN"}.to_cbor.hexs =3D> =E2=80=9Ca4 00 61 30 f9 00 00 64 2d 30 2e 30 f9 fe 00 63 4e 61 4e = f9 fe 00 63 4e 61 4e=E2=80=9D { 0: =E2=80=9C0=E2=80=9D, 0.0: =E2=80=9C-0.0=E2=80=9D, = NaN: =E2=80=9CNaN=E2=80=9D, NaN: =E2=80=9CNaN=E2=80=9D = } The reason is that 0.0 and -0.0 are considered equal for hashing = purposes, as are NaN and NaN, but not NaN and -NaN. Ouch. I didn=E2=80=99= t consider this language wart something that CBOR-Ruby should try to = fix. Both NaN variants are normalized to 0xf9fe00 by CBOR-Ruby, while = they canonically should be 0xf97e00 according to Section 3.9. It seems = that 0xf9fe00 is a bug (line 174 of ext/cbor/packer.h). Gr=C3=BC=C3=9Fe, Carsten From lambdav@orange.fr Mon Jul 23 09:52:57 2018 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 9C8CF130F20 for ; Mon, 23 Jul 2018 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 bQNKAbW2h0Vb for ; Mon, 23 Jul 2018 09:52:53 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFAE130EDD for ; Mon, 23 Jul 2018 09:52:52 -0700 (PDT) Received: from wwinf1f09 ([10.232.36.52]) by mwinf5d64 with ME id EGsp1y00N17W9RW03GspgB; Mon, 23 Jul 2018 18:52:49 +0200 X-ME-Helo: wwinf1f09 X-ME-Auth: bGFtYmRhdkBvcmFuZ2UuZnI= X-ME-Date: Mon, 23 Jul 2018 18:52:49 +0200 X-ME-IP: 2.6.95.204 Date: Mon, 23 Jul 2018 18:52:49 +0200 (CEST) From: Lambert DAVID Reply-To: Lambert DAVID To: Carsten Bormann , RFC Errata System Cc: Paul Hoffman , The IESG , cbor@ietf.org Message-ID: <68135766.11018.1532364769257.JavaMail.www@wwinf1f09> In-Reply-To: <9EA0357A-7B19-4FA9-B039-9D30AE53BD2E@tzi.org> References: <20180722161656.5B12EB813D1@rfc-editor.org> <9EA0357A-7B19-4FA9-B039-9D30AE53BD2E@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11017_502791473.1532364769257" X-Originating-IP: [2.6.95.204] X-WUM-FROM: |~| X-WUM-TO: |~||~| X-WUM-CC: |~||~||~| X-WUM-REPLYTO: |~| Archived-At: X-Mailman-Approved-At: Tue, 24 Jul 2018 00:11:04 -0700 Subject: Re: [Cbor] [Technical Errata Reported] RFC7049 (5434) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:55:22 -0000 ------=_Part_11017_502791473.1532364769257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, =C2=A0 thank you for the answer. =C2=A0 Effectively, UBJSON seems to have changed recently. The specification histo= ry is not present on the official website. It is difficult to=C2=A0use a specification that can change=C2=A0and do not= preserve previous versions of the specification for references. =C2=A0 The=C2=A0UBJSON specification seems to have=C2=A0been modified=C2=A0in 2013= : 2013-01-11=C2=A0 https://web.archive.org/web/20130111190558/http://ubjson.o= rg:80/type-reference/ =C2=A0 =C2=A0 2013-06-04=C2=A0 https://web.archive.org/web/20130604130935/http://ubjson.o= rg/type-reference/ =C2=A0 UBJSON was quite new in 2013 and its specification may have not been=C2=A0m= ature or not a final version. I think the specification could have changed because there was no much=C2= =A0UBJSON implementations. But 5 years later in 2018, the UBJSON has not changed since this=C2=A0versi= on. Changing=C2=A0the UBJSON specification in 2018 would have great impact on e= xisting implementations. =C2=A0 =C2=A0 About RFC 8060, as it has been created in 2017, 4 years after the change,= =C2=A0we can assume it refers to the new specification. =C2=A0 =C2=A0 About CBOR, I found it to be a very good serialization format, comparing it= against MessagePack because=C2=A0CBOR=C2=A0encoding is similar for all dat= a types, and=C2=A0allows=C2=A0extending the data types that can be encoded = via Tags, with a very wide range for tag numbers. =C2=A0 =C2=A0 Best regards, David =C2=A0 > Message du 22/07/18 19:15 > De : "Carsten Bormann"=20 > A : "RFC Errata System"=20 > Copie =C3=A0 : "Paul Hoffman"=20 , "The IESG" , lambdav@orange.fr, cbor@ietf.org > Objet : Re: [Technical Errata Reported] RFC7049 (5434) >=20 > Hi David, >=20 > thank you for this report! >=20 > It appears =E2=80=9CUBJSON=E2=80=9D is now a specification completely dif= ferent from what it was in 2013, sharing only the name. The peril of refere= ncing a website for a specification. If you have more information about wha= t happened to =E2=80=9CUBJSON" in the last five years, this could be quite = interesting. >=20 > I would propose classifying this as =E2=80=9Chold for document update=E2= =80=9D, with a view of removing UBJSON from the illustrative appendix: the = use will create confusion and the example is not at all necessary for makin= g use of CBOR. (The updated text of RFC 7049 is being actively worked on by= the CBOR WG, draft at https://github.com/cbor-wg/CBORbis =E2=80=94 comment= s on this document are very welcome!) >=20 > (As a separate observation, I will note that the Experimental RFC 8060 re= ferences UBJSON without specifying whether the old or the new specification= is intended.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On Jul 22, 2018, at 18:16, 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: > > http://www.rfc-editor.org/errata/eid5434 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: LAMBERT David=20 > >=20 > > Section: E.6 > >=20 > > Original Text > > ------------- > > | | | | > > | UBJSON | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 | > > | | 42 03 | 42 03 45 | > > | | | | > >=20 > >=20 > > Corrected Text > > -------------- > > | | | | > > | UBJSON | 5B 23 55 02 55 01 5B 23 | 5B 55 01 5B 55 02 55 03 | > > | | 55 02 55 02 55 03 | 5D 5D | > > | | | | > >=20 > >=20 > > Notes > > ----- > > According to UBJSON type specification available at > > http://ubjson.org/type-reference/ arrays are encoded with square-bracke= ts '[' and ']', or with '[' followed by '#' to specify the element count. > >=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 >=20 > ------=_Part_11017_502791473.1532364769257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Carsten,

=C2=A0

thank you for the answer.

=C2=A0

Effectively, UBJSON seems to have changed recently. The specification hi= story is not present on the official website.

It is difficult to=C2=A0use a specification that can change=C2=A0and do = not preserve previous versions of the specification for references.

=C2=A0

The=C2=A0UBJSON specification seems to have=C2=A0been modified=C2=A0in 2= 013 :

2013-01-11=C2=A0 https://web.archive.org/web/2013011119= 0558/http://ubjson.org:80/type-reference/

=C2=A0

=C2=A0

2013-06-04=C2=A0 https://web.archive.org/web/2013060413093= 5/http://ubjson.org/type-reference/

=C2=A0

UBJSON was quite new in 2013 and its specification may have not been=C2= =A0mature or not a final version.

I think the specification could have changed because there was no much= =C2=A0UBJSON implementations.

But 5 years later in 2018, the UBJSON has not changed since this=C2=A0ve= rsion.

Changing=C2=A0the UBJSON specification in 2018 would have great impact o= n existing implementations.

=C2=A0

=C2=A0

About RFC 8060, as it has been created in 2017, 4 years after the change= ,=C2=A0we can assume it refers to the new specification.

=C2=A0

=C2=A0

About CBOR, I found it to be a very good serialization format, comparing= it against MessagePack because=C2=A0CBOR=C2=A0encoding is similar for all = data types, and=C2=A0allows=C2=A0extending the data types that can be encod= ed via Tags, with a very wide range for tag numbers.

=C2=A0

=C2=A0

Best regards,

David

=C2=A0

> Message du 22/07/18 19:15
> De : "Carsten Borm= ann" <cabo@tzi.org>
> A : "RFC Errata System" <rfc-editor@= rfc-editor.org>
> Copie =C3=A0 : "Paul Hoffman" <paul.hoffman= @vpnc.org>, "The IESG" <iesg@ietf.org>, lambdav@orange.fr, cbor@ie= tf.org
> Objet : Re: [Technical Errata Reported] RFC7049 (5434)
>
> Hi David,
>
> thank you for this report!=
>
> It appears =E2=80=9CUBJSON=E2=80=9D is now a specific= ation completely different from what it was in 2013, sharing only the name.= The peril of referencing a website for a specification. If you have more i= nformation about what happened to =E2=80=9CUBJSON" in the last five years, = this could be quite interesting.
>
> I would propose class= ifying this as =E2=80=9Chold for document update=E2=80=9D, with a view of r= emoving UBJSON from the illustrative appendix: the use will create confusio= n and the example is not at all necessary for making use of CBOR. (The upda= ted text of RFC 7049 is being actively worked on by the CBOR WG, draft at h= ttps://github.com/cbor-wg/CBORbis =E2=80=94 comments on this document are v= ery welcome!)
>
> (As a separate observation, I will note = that the Experimental RFC 8060 references UBJSON without specifying whether= the old or the new specification is intended.)
>
> Gr=C3= =BC=C3=9Fe, Carsten
>
>
> > On Jul 22, 2018, a= t 18:16, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
&g= t; >
> > The following errata report has been submitted for = RFC7049,
> > "Concise Binary Object Representation (CBOR)".
> >
> > --------------------------------------
>= > You may review the report below and at:
> > http://www.rfc= -editor.org/errata/eid5434
> >
> > -----------------= ---------------------
> > Type: Technical
> > Reporte= d by: LAMBERT David <lambdav@orange.fr>
> >
> >= ; Section: E.6
> >
> > Original Text
> > = -------------
> > | | | |
> > | UBJSON | 61 02 42 01 = 61 02 42 02 | 61 ff 42 01 61 02 42 02 |
> > | | 42 03 | 42 03 45= |
> > | | | |
> >
> >
> > Co= rrected Text
> > --------------
> > | | | |
>= > | UBJSON | 5B 23 55 02 55 01 5B 23 | 5B 55 01 5B 55 02 55 03 |
&= gt; > | | 55 02 55 02 55 03 | 5D 5D |
> > | | | |
> &= gt;
> >
> > Notes
> > -----
> &g= t; According to UBJSON type specification available at
> > http:= //ubjson.org/type-reference/ arrays are encoded with square-brackets '[' an= d ']', or with '[' followed by '#' to specify the element count.
> = >
> > Instructions:
> > -------------
> &= gt; 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 necessa= ry.
> >
> > --------------------------------------<= br />> > RFC7049 (draft-bormann-cbor-09)
> > -------------= -------------------------
> > Title : Concise Binary Object Repr= esentation (CBOR)
> > Publication Date : October 2013
> = > Author(s) : C. Bormann, P. Hoffman
> > Category : PROPOSED = STANDARD
> > Source : IETF - NON WORKING GROUP
> > Ar= ea : N/A
> > Stream : IETF
> > Verifying Party : IESG=
> >
>
>
------=_Part_11017_502791473.1532364769257-- From nobody Tue Jul 24 10:02:28 2018 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 5412413115F for ; Tue, 24 Jul 2018 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nq3w0zuvYvf for ; Tue, 24 Jul 2018 10:02:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2745130EFE for ; Tue, 24 Jul 2018 10:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6OH2JrH020280; Tue, 24 Jul 2018 19:02:19 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Zl5k6QVzzDXVP; Tue, 24 Jul 2018 19:02:18 +0200 (CEST) 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: <66628646-c25f-b903-8a54-67bc54f9c0aa@seantek.com> Date: Tue, 24 Jul 2018 19:02:18 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 554144536.931028-1922ce5b7c8a10f12eaf28d4f60ea3e9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A71EE5-870B-4772-BC2C-1D0905CFAC01@island-resort.com> <6BCE8035-8D56-4E72-ACFE-26F73113D0DC@seantek.com> <63564AB6-432F-4BA6-9913-A1B5E7D9098F@tzi.org> <2337C44A-B88C-4FBF-AA1A-48B76C074C92@tzi.org> <3E7A0AC4-7000-4FE8-BBDE-97F11533CAFA@tzi.org> <328B11BB-6E16-49A6-B507-D895A20FDFC6@seantek.com> <4574B09C-38C6-4FA1-940D-EF50A4A7B5F3@tzi.org> <8B84A99E-3DB4-4CE9-AC44-4CA595E2D63A@seantek.com> <9AA0D6B4-3C5A-4663-8E53-197114A4161B@tzi.org> <66628646-c25f-b903-8a54-67bc54f9c0aa@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Representation Variants in CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:02:27 -0000 Hi Sean, apparently, I read your message a bit out of context. > I acknowledge that I also made a stronger statement: "I would argue = that all generic CBOR decoders SHOULD check UTF-8." I still stand by = this statement, but did not, and do not, propose any changes to the RFC = 7049 text. (For me, this is not an RFC 2119 =E2=80=9CSHOULD=E2=80=9D, but an = RFC6919 =E2=80=9COUGHT TO=E2=80=9D, =E2=80=9CWOULD PROBABLY=E2=80=9D, or = maybe even =E2=80=9CMAY WISH TO=E2=80=9D.) As a quality of implementation statement, a generic CBOR decoder that = delivers invalid UTF-8 to its application and potentially then has the = application blow up with an exception in the unrelated place where that = UTF-8 is actually being used, is not so nice. But the trade-offs are = hard to weigh from the high vantage point of a data interchange format = specification. > RFC 3629 makes a normative statement: "Implementations of the decoding = algorithm above MUST protect against decoding invalid sequences." That = is actually a change from RFC 2279, and is noted as such in Section 12 = RFC 3629. Since the decoding is not done by CBOR, that requirement transfers right = to the UTF-8 decoder (if any) in the application. > There is a legitimate question as to whether "UTF-8 decoding" is = happening at all when dealing with CBOR. To the extent that CBOR is = ingested by a decoder and tstrs are converted to 16-bit code units, = i.e., UTF-16 (as, for example, in many JavaScript engines and APIs, = including but not limited to Windows and Apple/macOS/iOS), the = UTF-8-to-UTF-16 decoding algorithm is triggered. Right, many 1990=E2=80=99s languages have that problem, and a generic = CBOR decoder implementation for such a language probably wants to = perform that decoding for the application. RFC 3629 applies. > Similarly, if the source representation is in 16-bit code units = (UTF-16 or something like it), the UTF-16-to-UTF-8 encoding algorithm = will always be triggered when doing CBOR encoding. A properly = implemented UTF-16-to-UTF-8 encoding algorithm will never emit overlong = encodings or out-of-range bytes (C0, C1, F5-FF). Correct. > However, there are other situations when the tstr content is not = changed when CBOR is decoded (i.e., remains in 8-bit units, ostensibly = UTF-8). It is possible that the decoding algorithm is therefore not = triggered in those implementations. As in many languages designed after the time when =E2=80=9CUnicode=E2=80=9D= meant =E2=80=9C16-bit=E2=80=9D. > Alarm bells always sound in my head when data crosses a security = boundary. CBOR passing between two mutually trusted components is not a = security boundary. Loading CBOR from disk into memory is *probably* not = a security boundary, but it depends. However, when stuff is sent and = received across the Internet between different vendor implementations, = there is an obvious security boundary. The stuff purporting to be = "UTF-8" therefore really ought to be checked in most network-connected = circumstances. It is important that it be checked once. It need not be = checked repeatedly, but the problem is when the implementation in one = layer thinks that the checking will be done at a different layer, and = vice versa, resulting in no checks. Indeed, this is a general security consideration of RFC 3629. > There is a real danger that a CBOR decoder, which has no need to = convert from UTF-8 to UTF-16 in-memory, will just slap a label on the = chunk of data as "UTF-8 =3D good" and pass it along.=E2=80=A0=20 That may be what a performance-oriented generic decoder does. (It may = not even touch the data and just point to it by reference, as in = cn-cbor.) > What happens, then, when that in-memory CBOR needs to be serialized = back out? The encoder then needs to check whether the UTF-8 really *is* = good, No, it doesn=E2=80=99t =E2=80=94 it does not have that onus. > especially if it=E2=80=99s operating in =E2=80=9CStrict Mode" = (actually defined by RFC 7049) Then it does. > or some "preferred serialization" (the subject of this thread). Not sure that has anything to do with UTF-8 validation. > So, Thiago's comment on July 18: "Sure, the *encoder* should strive to = not send invalid UTF-8 anymore than duplicated keys in a map." is = actually correct. But is it the responsibility of the encoder to check = UTF-8 when the other parts of the software stack have already = represented that the UTF-8 is good? How many implementers can raise = their hands today and say, =E2=80=9Cyes, my CBOR implementation checks = that the UTF-8 string in memory really is well-formed UTF-8 before it is = encoded on the wire?" That would be an interesting subject of investigation, similar to the = floating point investigation you just started. Fun: http://cbor.me/?diag=3D%22%FF%22 http://cbor.me/?bytes=3D61(FF) (So much for my =E2=80=9Cquality of implementation=E2=80=9D comment = above, but then the problem probably is in the decoders/encoders for = diagnostic notation, which was never meant for interchange.) > None of this stuff is new. See Section 3 "Non-Visual Security Issues" = of Unicode Technical Report #36, Unicode Security Considerations. = In particular: Sections 3.1, = 3.5, 3.6, and 3.7. Ignore the sections that talk about normalization = because they are not relevant for this conversation (nothing in this = conversation has to do with NFC or whatever). No, but the application may actually require NFC=E2=80=A6 > I still maintain that no text from RFC 7049 needs to be changed in = this regard. But, proposed text about =E2=80=9Cbitwise comparison" and = the like should not be added either. Because UTF-8 has no representation variants (not considering = normalization), bitwise comparison is fine for map key comparison. = Unless the application needs normalized map keys, in which case some = additional checking is probably required in the application anyway. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 25 10:10:52 2018 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 37477130EB0; Wed, 25 Jul 2018 10:10:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253865013.15381.17002387302755749075@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:10:50 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-08-08 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:10:50 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-08-08 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:11:17 2018 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 A9D4B130F2A; Wed, 25 Jul 2018 10:11:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253866164.15406.5812478622762727726@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:11:01 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-08-22 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:11:10 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-08-22 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:11:25 2018 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 637BD130F01; Wed, 25 Jul 2018 10:11:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253867738.15402.7361057900343564750@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:11:17 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-09-05 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:11:23 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-09-05 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:11:39 2018 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 BECD4130FA5; Wed, 25 Jul 2018 10:11:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253869175.15469.7849979678693070446@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:11:31 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-09-19 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:11:37 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-09-19 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:11:56 2018 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 C702F131032; Wed, 25 Jul 2018 10:11:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253870579.15377.8989808411710240698@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:11:45 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-10-03 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:11:52 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-10-03 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:12:07 2018 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 3AF00130FFF; Wed, 25 Jul 2018 10:11:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253871520.15469.3009321594033811592@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:11:55 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-10-17 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:12:01 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-10-17 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Wed Jul 25 10:12:19 2018 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 D8908131029; Wed, 25 Jul 2018 10:12:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153253872681.15481.12873182929658010397@ietfa.amsl.com> Date: Wed, 25 Jul 2018 10:12:06 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2018-10-31 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:12:13 -0000 The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2018-10-31 from 15:00 to 16:00 UTC. Agenda: The CBOR working group will have conference calls running every two weeks through the end of October (basically, until IETF 103 in Bangkok). Day: every other Wednesday beginning on 8 August Dates: 8, 22 Aug; 5, 19, Sep; 3, 17, 31 Oct Time: 15:00 to 16:00 UTC Note that local time in Europe will change for the 31 October meeting. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing 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. Information about remote participation: WebEx details will be sent to the mailing list before each call (the details will be the same for all calls, but the messages will serve as reminders). From nobody Thu Jul 26 04:28:34 2018 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 2BB261310F8 for ; Thu, 26 Jul 2018 04:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Wz5UzO/I; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PR0O2jJX 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 V91Kqy3nrl7y for ; Thu, 26 Jul 2018 04:28:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 35EC9130F96 for ; Thu, 26 Jul 2018 04:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532604504; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=akRJt9K6fi8t00NnZLyALeQVHiaF4Qa/qvSmSli1PPs=; b=Wz5UzO/I/+KoXdMN8T0vw9ts8YiI3DzC8V5EZF2y4YwzgVpcV6cf6hQaavHzgTAh WBdK/TRXRm/kcyV5Wsz7OiEo15YOcvvLopSkm+F78Rzhu74CR6Js615htnmEXj6L y5dPmK4LdoSxMLBQxhL/oNWsEK+8QOwW1FQGsjHWvc8=; X-AuditID: c1b4fb3a-9e9ff700000079c1-24-5b59b0582302 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 91.6D.31169.850B95B5; Thu, 26 Jul 2018 13:28:24 +0200 (CEST) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESBMB505.ericsson.se (153.88.183.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 13:28:24 +0200 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 13:28:24 +0200 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 26 Jul 2018 13:28:23 +0200 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=JaKuwpNTeVF+2aJ+FOJCe9jPr/QplVwiK21R7vyCcIQ=; b=PR0O2jJXSAjwUTk13+oKg9vxeKCnxC1xN3uwkPWFx3X7piORM835fozbP7AI/oZdR630iZp6ff1R9vZHqWaRk7jTe5MvBDXfR5yf4rVZyQtP4/Z7uMADPEHVUXv/0vIOExMmjpnuAUQsOO3kv3OxYXdpZAg+42l/0fLx+ZiNCPg= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2450.eurprd07.prod.outlook.com (10.169.153.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.5; Thu, 26 Jul 2018 11:28:22 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::526:d874:dcbb:a11%3]) with mapi id 15.20.0995.008; Thu, 26 Jul 2018 11:28:22 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes IETF102 CBOR Thread-Index: AdQk07XZ1OOWyc3NQTS6JLn6Y/OWMQ== Date: Thu, 26 Jul 2018 11:28:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2450; 6:to0mIObzl+o2AN6TpPHyGjysX1YG22rHpuaJdENff1Ai1ADWbpG1By8U+oTFxOSYHXD5uI/IVznfNae0RBlLBXDeIo0xY9lLaxZQyks2h1C88aNxf+DgiRg2zDIDFh03Xy5hLGtOosPKffrc57wRJTT0UQ7pGHth1UwtbLdXUckU3I3KDSGl5ZxpAHapBWCgAs3xDq0Q6K3eCIEtQXTIEGVjHUuLGY6vHjSi9ySxvftjEZQjqoz142nw1SXkIqCq7VdFJjAEsaoFl92pWpRGkhx3FfUxr0LO9JaBVN+oME++Z1zg8/T1r1ip1hujipK7R3aVQXq6bUMEwKxzjqLvaO6xxPuMwknPWkSVsKu1CL9RwTJFMEVvZk5hD9h6y7fHIE17CfM3/seoXPdxRXFTerFoqtGS7POjvn8G63GzscgOS6mDcXgH1rJD21GsywQRzQmBnoLwRAiGW1vwJmF8nA==; 5:olYro2c11w0TS5oAN4+Od81ElyflngRIY266DP+NSZGsWtxYI1qDtNpWpR+5ztqIbXJPPPIkWVIbHAoi6PSJoXmLUVO+8IKS2/7oNV9yn1cD87Wrl8s+qDBdJin99Ftxl4vjNpQxucGTArjZ3XslNJnJ32ev3YXfzBOv4xnaIak=; 7:Sw0tS9NPtoKudvJcvZw+6V6gREOjEq3On60WZJ+qXBpwS/G5iw9W592TtMszeLAtKwYilLDDVJpqQJQEx+aquZsecCdH3Fimn+/XS/wtDl5FdpmrmtNMGAFiefGQugYU7IEaC+bRHjYNXaRjwIW+FYk0s0vFD3qs3jW5tAiDxbPcm/Ps+4x0kh15b84F9GjyWrkrwuQm06HP4dXt3GTXTV/B2OcbSmS7B6A+WZ1pNjsrXHDG0YhwwbaJmmaZJ0pC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 582098e1-b402-4de5-d4b4-08d5f2eae53b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2450; x-ms-traffictypediagnostic: AM5PR0701MB2450: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB2450; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2450; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(366004)(136003)(57704003)(53754006)(199004)(189003)(236005)(478600001)(33656002)(2906002)(966005)(53936002)(6436002)(55016002)(5640700003)(54896002)(9686003)(6306002)(14454004)(186003)(450100002)(74316002)(4326008)(6916009)(25786009)(7736002)(102836004)(26005)(8676002)(81156014)(81166006)(44832011)(1730700003)(5660300001)(7116003)(19609705001)(6506007)(2900100001)(97736004)(256004)(5250100002)(66066001)(2501003)(14444005)(106356001)(105586002)(486006)(2351001)(6116002)(3846002)(790700001)(476003)(99286004)(8936002)(316002)(86362001)(606006)(7696005)(5630700001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2450; H:AM5PR0701MB2737.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-microsoft-antispam-message-info: 2OKDV7pEtcV/qxz6AsrU92GyrUDF/YZPPzuyFmmfJdGp0JZbgmpgx75zalQBHJnteXev50LqaNeWhJj3KZsw1D6rbZUwef7vTsOBRkHKfrDbnc2bZX7GRbonuuX7QLcqes259Ep5Jm+yKftIXcqVSCO6yO75vefhtk1epocN+uaMdCCDXDG0XX4JGxHuThfAMBw9BozhWcr8bml91NvOy3E9ffOpeH4ELrgqqT1lhGeli9W2On0mPIfgOwsIb98UBq8edQSNi4w5cFgxrOVMu/Rp2QXcMgTBWywAAuPAYv6uWYopnNm88pWNQswm78nE1zDMtzAI9aQ49IfV0JfMbOKTqcQpl2gDNXw/ItWT2Lk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2737AA0BC953D818C9FA681B982B0AM5PR0701MB2737_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 582098e1-b402-4de5-d4b4-08d5f2eae53b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 11:28:22.3164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2450 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe89l52iujkvxQTFjYlB5SdGSkCiJ8EOFCIKXD7r0eCnd7BwT LRCNCF1p+9CK6WxOhiw172SohJuYLjNvRdgcYVNE0gqRzETN7czw2+//f/7v+zzPy0vjEiPp S+fKC1lOLsuTitwJTVJPUUhSe3Lq6R2rJLp2qxtFayqeERewOINhA4tHKe4xmWxebhHLhZ1P d8+xWepEBS/tqHj4z3O8DHVakBK50cBEwnjrJ1yJ3GkJM4Rg2WakBPEbgVavwv+LBk0rEoQB g9bKNacgGBUO6lmjK/YUA91qMymIbwhsHcOko42IiYGJuZ9O9mICQf1kUKRENI0z4bDRf8th H2H8oW32AS5EpLBtmkECh8LyaC3mYIIJgj7VYyeLmXRoaZh15tHu2bXyZifjjA98mddhwnYM GPrHcYG9Ycm+TTraAnMMqqZTBNsfpnQPncsAM0DByrqSFAoh8Eutdp29CtWGNlfIgmBmpcFV CIaxe1uUMEQGfLRWU4KvAH2vVSRwHlR+/eF67qPQVDVHCBeZcdhq36RUKKxm3+ACK+Cz8Q1Z 41zUEyyaeULwg6G+b1Uk8Clo1H/H9/j9gB3b79cjqgl58yzP52dHRISyXG4GzyvkoXK2sBPt /h9T9+a518i0eNGMGBpJPcSTuuRUCSkr4kvyzQhoXOolPtC8a4kzZSV3WE6Rxt3OY3kz8qMJ qY84Nis6RcJkywrZmyxbwHJ7VYx28y1D4SRXceOEnUqLTax5d9k0uRTSFXooazUg/cyIm+La xN2FxUZZpLblQ9x0zNsX84Ha9lGV29npwanahd6/a6qwobpHXYN4lF9s+eEAcrE4IeiKxyuv Ns5WKrfynvqU63B/oSn+YH7ZpY2dnvaEocqtgHUYS6w/XtoxQkVFJ2nVUoLPkYWfxDle9g8B FFXAOwMAAA== Archived-At: Subject: [Cbor] Minutes IETF102 CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 11:28:30 -0000 --_000_AM5PR0701MB2737AA0BC953D818C9FA681B982B0AM5PR0701MB2737_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I uploaded the minutes for the CBOR meeting at IETF102 on the datatracker: = https://datatracker.ietf.org/doc/minutes-102-cbor/ Big thanks to Dave Waltermire for taking them! Please let us know if you have any comment, and if you have actively partic= ipated, take a second to make sure that your comments were correctly captur= ed. Francesca -- CBOR WG Meeting IETF 102 - Montreal Tuesday, July 17, 2018, 13:30 - 15:30 Chairs: Barry Leiba, Francesca Palombini Minute takers: David Waltermire * Introduction [10'] : Chairs - slides https://datatracker.ietf.org/meeting= /102/materials/slides-102-cbor-chairs-00 ---------------------------------- Agenda bashing and status update Chairs provided a short status update based on content in the slides. WG documents: - slides https://datatracker.ietf.org/meeting/102/materials/s= lides-102-cbor-consolidated-01 * CDDL [60'] : Carsten https://tools.ietf.org/html/draft-ietf-cbor-cddl -------------------------------------------------- slide7: Jeffrey Yasskin: Q - There is not standard definition for path expression g= rammars. Carsten: We need to find a good reference for this. Jeffrey: We also need to define the mapping between parse expression syntax= and CDDL syntax. Slide8: Alexey: To use specification required, we need clear guidelines around what= is expected. Jim Schaad: Does the specification need to be public? Barry: Yes. If you don't need that, then expert review can be used. Sean Leonard: Not sure we need a control operator registry. Chairs: If we are going to have a registry, we need to define what will be = required. Do we need to establish a registry now. Paul Hoffman: It would be bad to delay creating a registry. I prefer expert= review over specification required. Barry: You are suggesting we do not need a specification for including an i= tem in the registry? Paul: Yes. Expert review provides a good level flexibility to support adequ= ate human review. Jim: If we do a CDDL 2, we should hold off on the registry until we have a = better handle on language details. Paul: It is fine to create a registry and to decide later how a CDDL 2 woul= d use the registry or do something else. Carsten: There are things that can't be fixed in CDDL that need a CDDL 2 (e= .g., cuts). This is a reason to do a CDDL 2. The point of the registry is t= o communicate to users that they can use CDDL even if their needed operator= is not available. The registry allows the user to define operators on thei= r own schedule, based on their ongoing needs. Barry: Expert review requires review by a group of people based on defined = criteria. Specification required add to "Expert Review" the need to referen= ce a specification. Chris Lemonios: We need a registry to provide an orderly way to extend the = language. Not having one will be a mess. Alexey: Who would be upset if CDDL provided this registry? Sean Leonard: I don't think a registry helps at this point in time. I don't= think its useful, and it will inhibit innovation. Dave Waltermire: A registry provides a way to have agreement on an approach= . Alexey: Expert review provides for some safety through review around how a = given item is approached. Chris Lemonios: Agree. Designated experts will encourage good specification= s. Mike Jones: With specifiation required, the registration template contains = a reference to the specification. Jim Schaad: What if I want to write a control operator that supports a clos= ed use? Brian Carpenter: The IETF doesn't like a lack of transparency around specif= ications. Alexey: I advise against "secret" specifications. Need expert review. Recom= mend specifications. Chairs: Add the registry. Make the requirement specification required. POLL: Any concerns? no. Strong consensus in the room to move forward with a= dding the registry and making the entries specification required. Slide 9: There was a discussion on how to handle equality of different types. Concer= ns were raised about being clear. It was proposed to use different operator= s for strings and numbers. (side 10) It was asked if there is a need to hav= e numeric variants of these operators. Jeffrey Yasskin: It might be safe to restrict .ne/.eq to only numeric types= . We can extend use of these operators to other types in CDDL 2. Slide 11: Carsten: Symmetry in provided operators is consistent with other historic l= anguages. For this reason, CDDL should provide for the same symmetry. Slide 13: Dave Waltermire: We need to avoid fragmentation in tooling that may be caus= ed by different serialization options. Henk: Extensions can also create a situation where serialization choices ge= t broken. Lawrance Lumblade: We should focus on the core specification and use case, = and let specialized use cases do something different. This keeps interopera= bility to a maximum within the core uses, while allowing for special case h= andling in small communities. Slide 16: Jim: (Issue 9) My concerns was with promoting an appendix subsection to a t= op-level appendix only. I don't think this will create a reference problem. Chairs: Asked for participants to speak up in the meeting or on the list if= they are unhappy with where CDDL is at this point. No concerns were raised= in the room. Chairs: Aiming for shipping the draft to Alexey in late August for AD revie= w. * CBOR specification status [30'] : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis -------------------------------------------------- * Flextime [10'] * CBOR Tag Definitions ---------------------- Dave Waltermire: Maybe use a wiki instead of a document. Alexey: Not a bad place to start Paul Hoffman: Not sure of the value of this. People often reinvent the same= extension. The problem is around how new participants can find what extens= ions already exist. Some discussion around what format to use: I/D, RFC, wiki. More discussion = needed. * Wrap-up [10'] : Chairs ------------------------ CDDL revision out by July 30 CBOR updated by October - August 31 for a next draft - Have bi-weekly conference calls starting the week of August 6th. - Chairs will setup the WG webex for this purpose. --_000_AM5PR0701MB2737AA0BC953D818C9FA681B982B0AM5PR0701MB2737_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I uploaded the minutes for the CBOR meeting at IETF1= 02 on the datatracker: https://data= tracker.ietf.org/doc/minutes-102-cbor/

Big thanks to Dave Waltermire for taking them!<= /o:p>

 

Please let us know if you have any comment, and if y= ou have actively participated, take a second to make sure that your comment= s were correctly captured.

 

Francesca

 

--

CBOR WG Meeting

IETF 102 - Montreal

Tuesday, July 17, 2018, 13:30 - 15:30

Chairs: Barry Leiba, Francesca Palombini<= /p>

 

 

Minute takers: David Waltermire

 

 

* Introduction [10'] : Chairs - slides https://datatracker.= ietf.org/meeting/102/materials/slides-102-cbor-chairs-00<= /p>

----------------------------------

 

  Agenda bashing and status update

Chairs provided a short status update based on content in t= he slides.

 

 

WG documents: - slides https://datatracker.ietf.org/meeting= /102/materials/slides-102-cbor-consolidated-01

* CDDL [60'] : Carsten

  https://tools.ietf.org/html/draft-ietf-cbor-cddl

--------------------------------------------------

 

slide7:

 

Jeffrey Yasskin: Q - There is not standard definition for p= ath expression grammars.

Carsten: We need to find a good reference for this.

Jeffrey: We also need to define the mapping between parse e= xpression syntax and CDDL syntax.

 

 

Slide8:

 

Alexey: To use specification required, we need clear guidel= ines around what is expected.

Jim Schaad: Does the specification need to be public?<= /o:p>

Barry: Yes. If you don't need that, then expert review can = be used.

Sean Leonard: Not sure we need a control operator registry.=

Chairs: If we are going to have a registry, we need to defi= ne what will be required. Do we need to establish a registry now.

Paul Hoffman: It would be bad to delay creating a registry.= I prefer expert review over specification required.

Barry: You are suggesting we do not need a specification fo= r including an item in the registry?

Paul: Yes. Expert review provides a good level flexibility = to support adequate human review.

Jim: If we do a CDDL 2, we should hold off on the registry = until we have a better handle on language details.

Paul: It is fine to create a registry and to decide later h= ow a CDDL 2 would use the registry or do something else.<= /p>

Carsten: There are things that can't be fixed in CDDL that = need a CDDL 2 (e.g., cuts). This is a reason to do a CDDL 2. The point of t= he registry is to communicate to users that they can use CDDL even if their needed operator is not available. The registry = allows the user to define operators on their own schedule, based on their o= ngoing needs.

Barry: Expert review requires review by a group of people b= ased on defined criteria. Specification required add to "Expert Review= " the need to reference a specification.

Chris Lemonios: We need a registry to provide an orderly wa= y to extend the language. Not having one will be a mess.<= /p>

Alexey: Who would be upset if CDDL provided this registry?<= o:p>

Sean Leonard: I don't think a registry helps at this point = in time. I don't think its useful, and it will inhibit innovation.

Dave Waltermire: A registry provides a way to have agreemen= t on an approach.

Alexey: Expert review provides for some safety through revi= ew around how a given item is approached.

Chris Lemonios: Agree. Designated experts will encourage go= od specifications.

Mike Jones: With specifiation required, the registration te= mplate contains a reference to the specification.

Jim Schaad: What if I want to write a control operator that= supports a closed use?

Brian Carpenter: The IETF doesn't like a lack of transparen= cy around specifications.

Alexey: I advise against "secret" specifications.= Need expert review. Recommend specifications.

 

 

Chairs: Add the registry. Make the requirement specificatio= n required.

 

POLL: Any concerns? no. Strong consensus in the room to mov= e forward with adding the registry and making the entries specification req= uired.

 

 

Slide 9:

 

There was a discussion on how to handle equality of differe= nt types. Concerns were raised about being clear. It was proposed to use di= fferent operators for strings and numbers. (side 10) It was asked if there is a need to have numeric variants of these oper= ators.

 

Jeffrey Yasskin: It might be safe to restrict .ne/.eq to on= ly numeric types. We can extend use of these operators to other types in CD= DL 2.

 

 

Slide 11:

 

Carsten: Symmetry in provided operators is consistent with = other historic languages. For this reason, CDDL should provide for the same= symmetry.

 

 

Slide 13:

 

Dave Waltermire: We need to avoid fragmentation in tooling = that may be caused by different serialization options.

Henk: Extensions can also create a situation where serializ= ation choices get broken.

Lawrance Lumblade: We should focus on the core specificatio= n and use case, and let specialized use cases do something different. This = keeps interoperability to a maximum within the core uses, while allowing for special case handling in small communities.<= o:p>

 

 

Slide 16:

 

Jim: (Issue 9) My concerns was with promoting an appendix s= ubsection to a top-level appendix only. I don't think this will create a re= ference problem.

 

 

Chairs: Asked for participants to speak up in the meeting o= r on the list if they are unhappy with where CDDL is at this point. No conc= erns were raised in the room.

 

Chairs: Aiming for shipping the draft to Alexey in late Aug= ust for AD review.

 

 

* CBOR specification status [30'] : Carsten

  https://tools.ietf.org/html/draft-ietf-cbor-7049bis<= o:p>

--------------------------------------------------

 

* Flextime [10']

 

 

* CBOR Tag Definitions

----------------------

 

Dave Waltermire: Maybe use a wiki instead of a document.

Alexey: Not a bad place to start

Paul Hoffman: Not sure of the value of this. People often r= einvent the same extension. The problem is around how new participants can = find what extensions already exist.

 

 

Some discussion around what format to use: I/D, RFC, wiki. = More discussion needed.

 

 

* Wrap-up [10'] : Chairs

------------------------

 

CDDL revision out by July 30

CBOR updated by October - August 31 for a next draft

- Have bi-weekly conference calls starting the week of Augu= st 6th.

- Chairs will setup the WG webex for this purpose.

 

 

--_000_AM5PR0701MB2737AA0BC953D818C9FA681B982B0AM5PR0701MB2737_-- From nobody Tue Jul 31 15:59:02 2018 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 DC8B1130E8E for ; Tue, 31 Jul 2018 15:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=linaro.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 uLw-3OJ2ITxZ for ; Tue, 31 Jul 2018 15:58:58 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 76428130DD1 for ; Tue, 31 Jul 2018 15:58:58 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g141-v6so6723829ita.4 for ; Tue, 31 Jul 2018 15:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=WoL567AfqJxF2ZysncHvqnKDRNgZLZMGMCdgQ4JLHjA=; b=PQCx2oCF321iYusCM31caxgzGU+FGyO3cc35cGU2py16MTzAvl2zRzlyvOpzN30Ixa fVeKPPzKaZkFh6PEkEap/MMVdE5xLoyh+2btdXtXKnqyB3P3CVPcyRH4rwiJ7RxnCpZk cXiMaJ+7iq9PqZZc+Wfx3VIS0OecRFVXugssk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=WoL567AfqJxF2ZysncHvqnKDRNgZLZMGMCdgQ4JLHjA=; b=aHZ3t2GjPa8d1n1OayzPR0NqyfM3xztGsEGBRgYqbB6eabp1AohPkbXYonmUjaSD+F 75szwJOku3rT8wdhw8IHSGE/K9NpMCsnoxwFF7xZLClNjLSJJfQqCn6CCPVv60lm/bIr pRENPhwDtuAMbCRRXxrScAGZqzdy47yLO0ksGEPS2EJsmkMOA0dYBzOk7GcGdsLyShyq 5L7I7dyKBFCD+xU+I+8nPycENaIDzS8mgj2jJCK7rSQTQtnJumMovkBgSauj0qlQDU5z WFsT1fhWgOeqBbgyamIGUyPVuQZ+GBqHVP6JDPCtpXWJsXQ2dd1V1oJ8O9Tjs4sHnFZw Vyzw== X-Gm-Message-State: AOUpUlEL5/JjfSxhXoofbz+8/Fion8M8kjfQerwiCdNrE4x45e9T1BKL CJ5iHayt+Kfb2X59Si021DInSWmwIq0sSg== X-Google-Smtp-Source: AAOMgpc33SFzf6PlLJQdKStLOOz4BHzerxqnGRt1WoG/VefKce+ZGOMZOttN/crMUSB8fLsZAdxs7g== X-Received: by 2002:a02:41d8:: with SMTP id n85-v6mr22368658jad.108.1533077937226; Tue, 31 Jul 2018 15:58:57 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id j199-v6sm2189347itb.43.2018.07.31.15.58.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 15:58:56 -0700 (PDT) Date: Tue, 31 Jul 2018 16:58:54 -0600 From: David Brown To: cbor@ietf.org Message-ID: <20180731225854.GA18176@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 22:59:01 -0000 I have written up a small (220 line) parser based on the draft-ietf-cbor-cddl-03 document. The code can be found at https://github.com/d3zd3z/suit-play/blob/master/cddl.rkt. I used the Racket lexer and parser tools to make this easier. I believe this parser parses (nearly) the same language described in the ABNF grammar in the draft (see below about spaces). However, a couple of observations: - in the rule for 'rule', since a 'type' by itself is a valid 'grpent', this rule is ambiguous. I made the parser work by simply commenting out the first alternate. I would gather that a tool using the output of this parser would have to store all entities, and check that a name used elsewhere as a type must be restricted to the 'type' form. - Spaces are a little complicated, and I'm not sure quite as intended. One production (for #6(...)) has a comment "note no space", however there are a few other places that are missing spaces (such as the space after the open paren on the "(" type ")" alternate. I found this much easier to handle by consuming spaces in the lexer and not making them part of the grammar at all. In order to do this, three things: "#" "6" ["." uint] "(" S type S ")" "#" DIGIT ["." uint] [uint] "*" [uint] must be captured by the lexer, since these production would make the grammar ambiguous unless the space is not allowed. I assume the intent is to interpret these with "maximal munch" (mostly thanks to the comma being optional). I also capture the repetition operation with numbers at lex time to avoid additional ambiguity. - The ABNF grammar references code points such as %x5D-10FFFD. Is it intentional to include the invalid range D800-DFFF, which are reserved for surrogate pairs in UTF-16? They are not considered valid codepoints for UTF-8, and depending on the tools/language used, may be rejected before codepoints are given to the parser. - The text of the draft states that hexidecimal numbers "... are case insensitive", however the ABNF grammar only accepts hexidecimal digits in uppercase. - There are productions allowed by the grammar whose meaning is not described by the text of the draft. For example: item = [ int => bstr ] is valid with the grammar, but it is unclear what this means. Perhaps this could describe an ordered map, or an array of pairs of items. Related are arrays that contain more than a single item: item = [ int, bstr, 5 ] - What is the intended interpretation of: groupname = (a b // c d) My parser interprets this as ((a b) // (c d)), however (a (b // c) d) is also a valid interpretation, an probably what is intended, especially if commas are used (a, b // c, d). - Related to the above, the grammar allows things like like grp = (// //) is this intentional? With some work, I believe it would be possible to transform this grammar into something LALR(1) (my grammar is part way there), but it would make some of the productions difficult to read. However, it may be a useful exercise because it would force any other ambiguities in the grammar. I wrote this starting with a LALR(1) parser, and wrote as much as I could without any shift/reduce conflicts, and reverted to a general backtracking parser near the end. The LALR(1) parser is significantly easier to debug, and tends to produce better error messages. David Brown From nobody Tue Jul 31 16:37:01 2018 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 D60CC130DF5 for ; Tue, 31 Jul 2018 16:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6__b80LIgPkG for ; Tue, 31 Jul 2018 16:36:57 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D1C128CF3 for ; Tue, 31 Jul 2018 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6VNas5l002354; Wed, 1 Aug 2018 01:36:54 +0200 (CEST) Received: from client-0052.vpn.uni-bremen.de (client-0052.vpn.uni-bremen.de [134.102.107.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41gCWn5vttzDXHZ; Wed, 1 Aug 2018 01:36:53 +0200 (CEST) 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: <20180731225854.GA18176@davidb.org> Date: Wed, 1 Aug 2018 01:36:52 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 554773011.046072-80f261a2adad34a6f502e855f3883302 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180731225854.GA18176@davidb.org> To: David Brown X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:37:00 -0000 Hi David, Thanks for doing this work! It=E2=80=99s already late here, so I=E2=80=99ll save the full follow-up = for tomorrow (the space stuff needs me to be awake), but let me just = amuse myself with the frequency with which one little detail tends to = trip up ABNF users. One other detail before: > - The ABNF grammar references code points such as %x5D-10FFFD. Is > it intentional to include the invalid range D800-DFFF, which are > reserved for surrogate pairs in UTF-16? They are not considered > valid codepoints for UTF-8, and depending on the tools/language > used, may be rejected before codepoints are given to the parser. Since CDDL is encoded in UTF-8, the invalid code points cannot happen. So %x5D-10FFFD is meant as a shortcut for =E2=80=9Call the valid code = points in this space=E2=80=9D. There is no need for redoing the work of the UTF-8 decoder in the = grammar. And now to my favorite ABNF trap:=20 > - The text of the draft states that hexidecimal numbers "... are > case insensitive", however the ABNF grammar only accepts > hexidecimal digits in uppercase. Let=E2=80=99s see, HEXDIG =3D DIGIT / =E2=80=9CA" / "B" / "C" / "D" / "E" / "F" Since ABNF is case-insensitive, this does cover both lower and upper = case. (The same is true for 0x, 0b, h, b64 etc. Don=E2=80=99t feel bad, *every* ABNF user trips up on this at least = once=E2=80=A6 It is highly unintuitive in 2018, and hence RFC 7405, which is not = needed by CDDL as all language features [not the rule names, though!] = are indeed case insensitive.) OK, let me answer a few more: > - There are productions allowed by the grammar whose meaning is not > described by the text of the draft. For example: >=20 > item =3D [ int =3D> bstr ] >=20 > is valid with the grammar, but it is unclear what this means. An array with a single bstr in it, as in these three examples: $ cddl -<<<"item =3D [ int =3D> bstr ]" gen 3 [h'76697065726C696B65'] [h'6F63756C6F63657068616C6963'] [h=E2=80=99726572697365'] I=E2=80=99m curious what part of the existing text is unclear about = this. > Perhaps this could describe an ordered map, or an array of pairs > of items. Related are arrays that contain more than a single > item: >=20 > item =3D [ int, bstr, 5 ] $ cddl -<<<"item =3D [ int, bstr, 5 ]" gen 3 [1137, h'6D6974696761626C65', 5] [-389, h'4E6567726F7068696C65', 5] [114, h=E2=80=99536F726768756D', 5] >=20 > - What is the intended interpretation of: >=20 > groupname =3D (a b // c d) >=20 > My parser interprets this as ((a b) // (c d)), Yes. Precedence of // is below , > however > (a (b // c) d) is also a valid interpretation, Maybe it is a bit too late in Europe already, but I don=E2=80=99t see = how to derive the latter from the grammar (assuming we use the grammar = to =E2=80=9Cparse=E2=80=9D the sentences of the language). Can you give = the derivation? > an probably what is > intended, especially if commas are used (a, b // c, d). Again, precedence of // is below , =E2=80=94 so ((a, b) // (c, d)) is = what is supposed to happen. (As with ABNF, it is never wrong to add a few parentheses instead of = relying on precedences, but experienced CDDL specifiers like it that you = can express choices between these sequences without a lot of clutter.) > - Related to the above, the grammar allows things like like >=20 > grp =3D (// //) >=20 > is this intentional? It is a redundant way of saying grp =3D () (That group is always an empty sequence.) Thanks for finding a bug in my tool :-) > With some work, I believe it would be possible to transform this > grammar into something LALR(1) (my grammar is part way there), but it > would make some of the productions difficult to read. However, it may > be a useful exercise because it would force any other ambiguities in > the grammar. The CDDL grammar has not been made easy for people writing parsers, but = for people writing specifications=E2=80=A6 But I=E2=80=99d sure like to = know whether it can be made LALR(1) =E2=80=94 I=E2=80=99d say, it needs = a lookahead of 2. > [=E2=80=A6] produce better error messages. Yes, that may indeed be possible. But redoing the grammar so it works = with a lookahead of 1 doesn=E2=80=99t seem possible to me without = completely changing the language. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 31 16:44:32 2018 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 CA4D1130E96 for ; Tue, 31 Jul 2018 16:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB7b1HrcDcfF for ; Tue, 31 Jul 2018 16:44:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25464128CF3 for ; Tue, 31 Jul 2018 16:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w6VNiRHV008229; Wed, 1 Aug 2018 01:44:27 +0200 (CEST) Received: from client-0052.vpn.uni-bremen.de (client-0052.vpn.uni-bremen.de [134.102.107.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41gChV6K4bzDXHc; Wed, 1 Aug 2018 01:44:26 +0200 (CEST) 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, 1 Aug 2018 01:44:26 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 554773464.025152-252c1f3d8b98684fd7569372330b4fba Content-Transfer-Encoding: quoted-printable Message-Id: <12B48231-0A9B-489B-8EED-36D8FE43FC6C@tzi.org> References: <20180731225854.GA18176@davidb.org> To: David Brown X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 23:44:32 -0000 On Aug 1, 2018, at 01:36, Carsten Bormann wrote: >=20 > (The same is true for 0x, 0b, h, b64 etc. > Don=E2=80=99t feel bad, *every* ABNF user trips up on this at least = once=E2=80=A6 > It is highly unintuitive in 2018, and hence RFC 7405, which is not = needed by CDDL as all language features [not the rule names, though!] = are indeed case insensitive.) Actually, h and b64 are not: bsqual =3D %x68 ; "h" / %x62.36.34 ; "b64" Should we change this for consistency? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 31 17:07:05 2018 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 21452130ED0 for ; Tue, 31 Jul 2018 17:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=linaro.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 kxatMkxi7Dr9 for ; Tue, 31 Jul 2018 17:07:00 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7A2130EAC for ; Tue, 31 Jul 2018 17:07:00 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id h23-v6so6907479ita.5 for ; Tue, 31 Jul 2018 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=MSMykChspq4Ta1oIiFuODBCHsosMGLixyF7i0U7FTZI=; b=BRAtAvh0DeM3Ks6s63XzhBZW2n3IxYxFackDQsK/Z3tTfIzt2brX3F/icJwJ4Hn3+B JX3RvNpZSIN9wdI+82mIef7QLBam340ZIfLn+7A3fyX5UM7RuluTA3WWBMHj1HSey5AR ToRjQRyzI4vHABqwQMs/q8Q6U1lJeKYra2SQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=MSMykChspq4Ta1oIiFuODBCHsosMGLixyF7i0U7FTZI=; b=MU2yE2JvfWyagmFEoIME47PPdmWmDgeade1PlwiBUXmIO1Al53hXaES3duuFMf9EJ5 Mztxuo8OWgZq4Vsk13/MOtvG4uU2NDXTSno8GpBHMy6gmagdDC9cOeiZiUQYJKN7n4QS /eFzFbUGcKsi2odOFZMPGEf4D4RRe0H5UXNWz2laMBpeXkMFbGFvzflt3Mw00LjZhC5y +6S3PzbSSBCItt7P0Qjy2lKygfhYe2zyZ4QtlA6A8+KeZS3N9PW5biOUWvj0zmwHclVC Z5gjH8df0ulRB7iz0gET5OAgf/FfatbQE4bU8P0xZX5hDX6JdI/82F+tf+EbZtBAlrUK z1fw== X-Gm-Message-State: AOUpUlGOLp0DrpbS2enRE9Zjvfb0o5SQUTCczCJW/BoS5skWnKrpwjK3 naK4jxJOWPzLJ72+XCubb/TFS/eVF4/QDQ== X-Google-Smtp-Source: AAOMgpeeE6fWIraHoYqfQ38jOiNlOyrluPPlwy2HpPtUzQmLdiq+UTvB5xIRgt7o5hQbR8/74zZSoA== X-Received: by 2002:a02:b559:: with SMTP id z25-v6mr22032053jaj.27.1533082019316; Tue, 31 Jul 2018 17:06:59 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id 84-v6sm2017340ita.35.2018.07.31.17.06.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 17:06:58 -0700 (PDT) Date: Tue, 31 Jul 2018 18:06:57 -0600 From: David Brown To: Carsten Bormann Cc: cbor@ietf.org Message-ID: <20180801000657.GA27353@davidb.org> References: <20180731225854.GA18176@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 00:07:03 -0000 On Wed, Aug 01, 2018 at 01:36:52AM +0200, Carsten Bormann wrote: >And now to my favorite ABNF trap: > >> - The text of the draft states that hexidecimal numbers "... are >> case insensitive", however the ABNF grammar only accepts >> hexidecimal digits in uppercase. > >Let’s see, > >HEXDIG = DIGIT / “A" / "B" / "C" / "D" / "E" / "F" > >Since ABNF is case-insensitive, this does cover both lower and upper case. Yeah, I missed that section of ABNF where it states that _strings_ are case insensitive. That is certainly not intuitive, and makes specifying case-sensitive languages tedious. >OK, let me answer a few more: > >> - There are productions allowed by the grammar whose meaning is not >> described by the text of the draft. For example: >> >> item = [ int => bstr ] >> >> is valid with the grammar, but it is unclear what this means. > >An array with a single bstr in it, as in these three examples: >$ cddl -<<<"item = [ int => bstr ]" gen 3 >[h'76697065726C696B65'] >[h'6F63756C6F63657068616C6963'] >[h’726572697365'] This comes from the description of 'struct', then. >> item = [ int, bstr, 5 ] > >$ cddl -<<<"item = [ int, bstr, 5 ]" gen 3 >[1137, h'6D6974696761626C65', 5] >[-389, h'4E6567726F7068696C65', 5] >[114, h’536F726768756D', 5] Does this mean that an array specification [ ... ] defaults to allowing only a single entity? This would require an occurrence specification on any arrays, and is certainly not how I see other drafts that use CDDL interpret it (even though it is not stated explicitly). I would assume that the above should allow: [ 1, h'1AB2', 5 ] [] [ 1, h'1AB2', 5, 7, h'5421' 5 ] etc But I guess that currently requires an explicit occurrence indicator. This does seem counter-intuitive to me, since CDDL notates structs and arrays the same way, yet the array requires the explicity occurrence indicator. David From nobody Tue Jul 31 21:06:37 2018 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 39F82130EB7 for ; Tue, 31 Jul 2018 21:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 tjjGw0dYXrIS for ; Tue, 31 Jul 2018 21:06:32 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7892B130E96 for ; Tue, 31 Jul 2018 21:06:32 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id r3-v6so7039874ybo.4 for ; Tue, 31 Jul 2018 21:06:32 -0700 (PDT) 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=xKwHWm4GpIsG8NWL9IMJtsC1S0gcd9+9iDthp0V8N4c=; b=mfFh3jydPzFXuxHsBppXQ1ZO35Zs5RrNF6uHOtDIkSUmT78ko6ZeDusfLa+TpvwvQv f0F1Ev0VfI1GWoikE+9BsJcgnORITBDpWojZh72r6FlY4BPRafLLoh1GFCMLonfu5dZK /Mlfmh2Nt7LNAjjcLBDaGzCgr141aUlYUJpf8= 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=xKwHWm4GpIsG8NWL9IMJtsC1S0gcd9+9iDthp0V8N4c=; b=Tj4RG2a66k/FOGO/gjdmdgh8dzkr3FXsCt6peKjd1iRle0auIaYkPBpKoyZFDqzjm5 Q2IuvCv8tloFS8l+uvwVWFpiurpbbXnBvfK/X8pcopZfIWTrUpDAsylCHfBtwma751DF G/J7RPRGY8OnihB7YAB3xnQxa9kWtXVVRVVxEUWe+cIQWiK3VABnIW7+lF5nY68RAOD9 BoPPTfB9nPY35D5K2whXWSMfU7Njfn7PoPU9JJqwbmsovdQaD5QkQ92kEBj0aClaQrby l1V87o3DRvKs3u/DI2YOsaLBU5e/ilDx87VUw7diI0Z5OANYgqFNNk1bgXu65epdo1nz 5Vnw== X-Gm-Message-State: AOUpUlGHYt9xPZieG5+9yO+2/Vosw1nyAsGVjk5FSoziDABGuFGW4A6g dlNPRSrlBoCttaOCQpWlJLGwdR/sndyRMFpEkF8WKI17ors= X-Google-Smtp-Source: AAOMgpdh9W5vSNOYzSw7likCCy0ZAzkGovLFB7Hle47hrhW1ITOFWLrxMzzl7mHqARkIak+8PexeApnUBpqigaqrxtY= X-Received: by 2002:a25:860a:: with SMTP id y10-v6mr12768683ybk.327.1533096391062; Tue, 31 Jul 2018 21:06:31 -0700 (PDT) MIME-Version: 1.0 References: <20180731225854.GA18176@davidb.org> In-Reply-To: From: Jeffrey Yasskin Date: Tue, 31 Jul 2018 21:06:19 -0700 Message-ID: To: Carsten Bormann Cc: david.brown@linaro.org, cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc404b057257d1ff" Archived-At: Subject: Re: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:06:36 -0000 --000000000000cc404b057257d1ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2018 at 4:37 PM Carsten Bormann wrote: > > - There are productions allowed by the grammar whose meaning is not > > described by the text of the draft. For example: > > > > item =3D [ int =3D> bstr ] > > > > is valid with the grammar, but it is unclear what this means. > > An array with a single bstr in it, as in these three examples: > > $ cddl -<<<"item =3D [ int =3D> bstr ]" gen 3 > [h'76697065726C696B65'] > [h'6F63756C6F63657068616C6963'] > [h=E2=80=99726572697365'] > > I=E2=80=99m curious what part of the existing text is unclear about this. That's the wrong question to ask when reviewing a specification. We have to find a piece of the text that's clear about the meaning we want. I believe the text that covers this is in Appendix C, https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#matching: / "[" S group S "]" > an array expression, which matches a CBOR array the elements of which, > when taken as values and complemented by a wildcard (matches anything) ke= y > each, match the group That is, [ int =3D> bstr ] matches a CBOR array when the elements of the array (e.g. ['mybstr']) are taken as values and given a matches anything key (so, [ : 'mybstr' ]), and then they match against the (int =3D> bstr) group: group =3D grpchoice S *("//" S grpchoice S) > A group matches any sequence of key/value pairs that matches any of the > choices given (again using Parse Expression Grammar semantics). > > grpchoice =3D *grpent > Each of the component groups is given as a sequence of group entries. For > a match, the sequence of key/value pairs given needs to match the sequenc= e > of group entries in the sequence given. > So (int=3D>bstr) matches (: 'mybstr') because the one key/value pair matches the one group entry, but (int=3D>bstr) doesn't match (: 'bstr1', : 'bstr2'), because 2 elements don't match 1. *This is less clear than it should be, since nothing says what it means for one sequence to "match" another sequence. Hence https://github.com/cbor-wg/cddl/issues/14 .* On Tue, Jul 31, 2018 at 5:07 PM David Brown wrote: > On Wed, Aug 01, 2018 at 01:36:52AM +0200, Carsten Bormann wrote: > >An array with a single bstr in it, as in these three examples: > > > >$ cddl -<<<"item =3D [ int =3D> bstr ]" gen 3 > >[h'76697065726C696B65'] > >[h'6F63756C6F63657068616C6963'] > >[h=E2=80=99726572697365'] > > This comes from the description of 'struct', then. > https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#structs is more a set of examples of how to use CDDL than a specification. The specification of =3D> is again in https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#matching under "memberkey" >> item =3D [ int, bstr, 5 ] > > > >$ cddl -<<<"item =3D [ int, bstr, 5 ]" gen 3 > >[1137, h'6D6974696761626C65', 5] > >[-389, h'4E6567726F7068696C65', 5] > >[114, h=E2=80=99536F726768756D', 5] > > Does this mean that an array specification [ ... ] defaults to > allowing only a single entity? As many items as the specification has entries, yes. > This would require an occurrence > specification on any arrays, and is certainly not how I see other > drafts that use CDDL interpret it (even though it is not stated > explicitly). > *Can you point to the other drafts you're thinking of here?* It'd be good to see examples of how people are understanding or misunderstanding CDDL, to motivate clarifications to the specification. I would assume that the above should allow: > > [ 1, h'1AB2', 5 ] > [] > [ 1, h'1AB2', 5, 7, h'5421' 5 ] > etc > > But I guess that currently requires an explicit occurrence indicator. > Yep. This does seem counter-intuitive to me, since CDDL notates structs and > arrays the same way, yet the array requires the explicity occurrence > indicator. > Structs also require explicit occurrence indicators if you want to repeat fields, except that's usually pointless because a CBOR map can only have one entry with a given key, and structs usually specify their keys with single-value types. Jeffrey --000000000000cc404b057257d1ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 31, 2018 at 4:37 PM Carsten Bormann <cabo@tzi.org> wrote:
> > - There = are productions allowed by the grammar whose meaning is not
> > = =C2=A0 described by the text of the draft.=C2=A0 For example:
> ><= br>> > =C2=A0 =C2=A0 =C2=A0item =3D [ int =3D> bstr ]
> >=
> > =C2=A0 is valid with the grammar, but it is unclear what this= means.
>
> An array with a single bstr in it, as in these thre= e examples:
>
> $ cddl -<<<"item =3D [ int =3D>= ; bstr ]" gen 3
> [h'76697065726C696B65']
> [h'= ;6F63756C6F63657068616C6963']
> [h=E2=80=99726572697365']
= >
> I=E2=80=99m curious what part of the existing text is unclear = about this.

That's the wrong question to ask when reviewing a sp= ecification. We have to find a piece of the text that's clear about the= meaning we want.

I believe the text that covers this is in Appendix= C, https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#matching:

=C2=A0 =C2=A0 = =C2=A0/ "[" S group S "]"
an array expression, which= matches a CBOR array the elements of which, when taken as values and compl= emented by a wildcard (matches anything) key each, match the group
That is, [ int =3D> bstr ] matches a CBOR array when the element= s of the array (e.g. ['mybstr']) are taken as values and given a ma= tches anything key (so, [ <matches-anything>: 'mybstr' ]), an= d then they match against the (int =3D> bstr) group:

=C2=A0 =C2=A0 group =3D grpchoice S *= ("//" S grpchoice S)
A group matches any sequence of key/value= pairs that matches any of the choices given (again using Parse Expression = Grammar semantics).
=C2=A0
=C2=A0 =C2=A0 grpchoice =3D *grpent
Each of = the component groups is given as a sequence of group entries. For a match, = the sequence of key/value pairs given needs to match the sequence of group = entries in the sequence given.

So (in= t=3D>bstr) matches (<matches-anything>: 'mybstr') because = the one key/value pair matches the one group entry, but (int=3D>bstr) do= esn't match (<matches-anything>: 'bstr1', <matches-any= thing>: 'bstr2'), because 2 elements don't match 1.


On Tue, Jul 31, 2018 at 5= :07 PM David Brown <david.brow= n@linaro.org> wrote:
On Wed, Aug 01, 2018 at 01:3= 6:52AM +0200, Carsten Bormann wrote:
>An array with a single bstr in = it, as in these three examples:


>$ cddl -<<<"it= em =3D [ int =3D> bstr ]" gen 3
>[h'76697065726C696B65= 9;]
>[h'6F63756C6F63657068616C6963']
>[h=E2=80=99726572= 697365']

This comes from the description of 'struct', th= en.

https://cbor-wg.github.io/cddl/dr= aft-ietf-cbor-cddl.html#structs is more a set of examples of how to use= CDDL than a specification. The specification of =3D> is again in=C2=A0<= a href=3D"https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#matching= ">https://cbor-wg.github.io/cddl/draft-ietf-cbor-cddl.html#matching und= er "memberkey"

>>=C2=A0 = =C2=A0 =C2=A0 item =3D [ int, bstr, 5 ]
>
>$ cddl -<<<= "item =3D [ int, bstr, 5 ]" gen 3
>[1137, h'6D697469676= 1626C65', 5]
>[-389, h'4E6567726F7068696C65', 5]
>[= 114, h=E2=80=99536F726768756D', 5]

Does this mean that an array = specification=C2=A0 [ ... ]=C2=A0 defaults to
allowing only a single ent= ity?=C2=A0

As many items as the specificati= on has entries, yes.
=C2=A0
This would require an= occurrence
specification on any arrays, and is certainly not how I see = other
drafts that use CDDL interpret it (even though it is not statedexplicitly).

Can you point to the o= ther drafts you're thinking of here? It'd be good to see exampl= es of how people are understanding or misunderstanding CDDL, to motivate cl= arifications to the specification.

I would as= sume that the above should allow:

=C2=A0 [ 1, h'1AB2', 5 ]=C2=A0 []
=C2=A0 [ 1, h'1AB2', 5, 7, h'5421' 5 ]
= =C2=A0 etc

But I guess that currently requires an explicit occurrenc= e indicator.

Yep.=C2=A0

<= /div>
This does seem counter-intuitive to me, since CDDL notates s= tructs and
arrays the same way, yet the array requires the explicity occ= urrence
indicator.

Structs also requ= ire explicit occurrence indicators if you want to repeat fields, except tha= t's usually pointless because a CBOR map can only have one entry with a= given key, and structs usually specify their keys with single-value types.=

Jeffrey

--000000000000cc404b057257d1ff-- From nobody Tue Jul 31 21:32:19 2018 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 908BB130EB7 for ; Tue, 31 Jul 2018 21:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=linaro.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 DWH7amE5zHg6 for ; Tue, 31 Jul 2018 21:32:14 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 4C9E9130E66 for ; Tue, 31 Jul 2018 21:32:14 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q9-v6so14991013ioj.8 for ; Tue, 31 Jul 2018 21:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=G8BszLljQjmTyW/Pso68z41Bc4qXY0PaXXh9egwWKgw=; b=XxBr/TTjSqc+yKDwJwXwygxf6v2TOeUbuQsGHg/js8S8grBbFeP+mzAUZRM/DtjXik ekMMdT+p1I8YeCgudFRH6P9dmvbqH5TF83aX8agVU1NbnGqUH9ppVLUvEN/K0l6ACnqc BLQQdzGDvEe0XuEYJ36i6mKlRugS63aj+9EpQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=G8BszLljQjmTyW/Pso68z41Bc4qXY0PaXXh9egwWKgw=; b=TCZbix+fpnjRbhsSnSxDUQbq+VLPm1wzTBbD9Ec2KsiaAKHL93BKhkErr9BY/fLpSb pt39JymtkhLO4+mTe+RB3XBF2bJdB007n5s5JgEp/EvnW6Xj/Qc5atwSepzbte7OGMd/ pzyxNKlKfNZSRPjPB+uqpO1H0nlnyPwcogBkxrZv9+Ydeq/0EzIMy913iVEderBSeH5d Mjia/LUsxdUZamfLIVdF1q5rlh5Xx8xfKbuGcvdQnAbmygotabiQmv47kWyuUoVwueGk cxS0ZfXd0WvjYnEaVmqDXh7l+ggBd9sR+tgtEGXvn/ooo+qy51CYY6Xm884c7nxsrwZL AwSQ== X-Gm-Message-State: AOUpUlGFRRn427iIbc4rKal9BaKy7lzHZYsbqmBlu3YNGWY7WkxsGnL6 tufg43cAN8epj0Pxh3ZwBgdf9w== X-Google-Smtp-Source: AAOMgpcNx6yzsTxRH83lp6TUnjDKXV8FTTvhIFxXv2WQahRl81AeYRGdsNkpsPpL5dtXlUDLkXsSZw== X-Received: by 2002:a6b:de05:: with SMTP id v5-v6mr2078846iog.121.1533097933422; Tue, 31 Jul 2018 21:32:13 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id t187-v6sm2663311ita.28.2018.07.31.21.32.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 21:32:12 -0700 (PDT) Date: Tue, 31 Jul 2018 22:32:10 -0600 From: David Brown To: Jeffrey Yasskin Cc: Carsten Bormann , cbor@ietf.org Message-ID: <20180801043210.GA26124@davidb.org> References: <20180731225854.GA18176@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Cbor] Parsing CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 04:32:18 -0000 On Tue, Jul 31, 2018 at 09:06:19PM -0700, Jeffrey Yasskin wrote: >Can you point to the other drafts you're thinking of here? It'd be good to see >examples of how people are understanding or misunderstanding CDDL, to motivate >clarifications to the specification. Specifically: https://datatracker.ietf.org/doc/draft-moran-suit-manifest/ There is, for example, a definition: Directive = [ int => bstr ] I suspect it was meant to be a map, but if I'm understanding the spec, this is an array containing a single bstr. SUIT has a need for something like a map, but where the order of the entries can be controlled. It sounds to me like: [ * (int, bstr) ] would be useful, or even more useful, instead of a bstr, a specific type, depending on what the int is. This is meaningful with a map and '=>' to give specific types for each int, but can this be specified for pairs like this. What SUIT currently has are constructs such as: [ ... preConditions: [ * PreCondition ], ... ] PreCondition = IdCondition / TimeCondition / ImageCondition / CustomCondition IdCondition = [vendor: 1 / class: 2/ device: 3, id: Uuid] TimeCondition = [installAfter: 4 / bestBefore: 5, time: Timestamp] ... Where it is an array of structure, where the first element of each structure is an int that gives the meaning/interpretation of the rest of the structure. Is there a better way to represent this? COSE, for example, uses a map, but its model is indeed a map, and there is no meaningful order to the entries. For SUIT, some of the values are indicating a specific sequence, and order needs to be maintained. Hopefully this makes sense, David