From nobody Fri Mar 1 13:12:48 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E65130EE9; Fri, 1 Mar 2019 13:10:01 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460107.6101.2890331373882842821.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:01 -0800 Archived-At: Subject: [Cbor] cbor - Requested session has been scheduled for IETF 104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:11 -0000 Dear Francesca Palombini, 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) Thursday, 28 March 2019, Morning Session I 0900-1030 Room Name: Karlin 3 size: 60 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/cbor.ics Request Information: --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini 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 iasa2 core ace t2trg cose 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 early Friday morning --------------------------------------------------------- From nobody Fri Mar 1 18:15:58 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7403126D00; Fri, 1 Mar 2019 18:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 X7BDtjqO8uTP; Fri, 1 Mar 2019 18:15:53 -0800 (PST) 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 E13EF129284; Fri, 1 Mar 2019 18:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x222FeOa008142; Sat, 2 Mar 2019 03:15:46 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (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 44B8yh472nz1Bp8; Sat, 2 Mar 2019 03:15:40 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 2 Mar 2019 03:15:37 +0100 Message-Id: <932D3C6C-E9F7-4B9D-B335-4B43ADA0936C@tzi.org> To: ace , core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF104: FINAL AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 02:15:57 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF104. Remember that, even though this will now go to the printers, there is still some potential for changes. The somewhat annoying coflicts cose/teep and lpwan/t2trg remain. I also don't like that I'll have to miss the cacao BOF (vs. core), dinrg/suit, coinrg/git. rats has been swapped against the paw/saag conflict. All times are CET (Central European Time) =3D=3D UTC +1 hours. Note = that there is no daylight saving time in effect at the time in Europe (this starts on the Sunday *after* IETF). (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 FRIDAY, March 22, 2019 -- Fri 0930=E2=80=931830 T2TRG Work Meeting -- Istanbul room SATURDAY/SUNDAY, March 23/24. 2019 -- Hackathon (including various interops) (Grand Hilton Ballroom) -- Sun 1700-1900 Welcome Reception - Congress Hall 1/2 -- Sun 1800-2000 Hot RFC Lightning Talks - Congress Hall 3 MONDAY, March 25, 2019 0900-1100 Morning Session I Congress H 3 ART dispatch Dispatch WG - Joint with ARTAREA Congress H 2 INT 6man IPv6 Maintenance WG Congress H 1 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Karlin 3 RTG bier Bit Indexed Explicit Replication WG 1120-1220 Morning Session II Congress H 3 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Karlin 3 RTG bier Bit Indexed Explicit Replication WG Congress H 2 SEC tls Transport Layer Security WG Karlin 1/2 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Karlin 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H 2 IRTF irtfopen IRTF Open Meeting Congress H 3 SEC secdispatch Security Dispatch WG 1610-1810 Afternoon Session II Congress H 2 ART httpbis Hypertext Transfer Protocol WG Congress H 3 IAB smart Stopping Malware and Researching Threats Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Grand BR IRTF qirg Quantum Internet Proposed Research Group Karlin 3 RTG *** roll Routing Over Low power and Lossy = networks WG Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H 1 TSV tsvwg Transport Area Working Group WG TUESDAY, March 26, 2019 0900-1100 Morning Session I Karlin 3 ART uta Using TLS in Applications WG - 1000 - = 1100 Grand BR INT homenet Home Networking WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG Karlin 1/2 SEC *** teep Trusted Execution Environment = Provisioning WG Congress H 2 TSV quic QUIC WG 1120-1220 Morning Session II Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Congress H 1 IRTF qirg Quantum Internet Proposed Research Group Congress H 3 TSV tsvwg Transport Area Working Group WG 1350-1550 Afternoon Session I Berlin/Brussels ART *** core Constrained RESTful Environments WG Karlin 1/2 OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H 1 SEC mls Messaging Layer Security WG Congress H 3 TSV tsvarea Transport Area Open Meeting 1610-1810 Afternoon Session II Grand BR INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Congress H 1 IRTF*** t2trg Thing-to-Thing Congress H 2 SEC tls Transport Layer Security WG WEDNESDAY, March 27, 2019 0900-1100 Morning Session I Karlin 1/2 IRTF*** dinrg Decentralized Internet Infrastructure Congress H 1 RTG detnet Deterministic Networking WG Grand BR RTG rift Routing In Fat Trees WG Congress H 3 SEC *** suit Software Updates for Internet of Things = WG Congress H 2 TSV quic QUIC WG 1120-1320 Morning Session II Grand BR IRTF cfrg Crypto Forum - 12:20 - 13:20 Grand BR SEC acme Automated Certificate Management = Environment WG - 11:20 - 12:20 1500-1700 Afternoon Session I Grand BR OPS wgtlgo Technology Deep Dive - Modern Router = Architecture BOF THURSDAY, March 28, 2019 0900-1030 Morning Session I Karlin 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Congress H 3 IRTF panrg Path Aware Networking RG Athens/Barcel. RTG babel Babel routing protocol WG Congress H 1 SEC mls Messaging Layer Security WG Berlin/Brussels SEC oauth Web Authorization Protocol WG 1050-1220 Morning Session II Congress H 3 GEN git GitHub Integration and Tooling WG Congress H 1 IRTF coinrg Computing in the Network Congress H 2 IRTF maprg Measurement and Analysis for Protocols 1350-1550 Afternoon Session I Congress H 3 ART httpbis Hypertext Transfer Protocol WG Grand BR INT *** paw Predictable and Available Wireless BOF Athens/Barcel. OPS v6ops IPv6 Operations WG Congress H 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Athens/Barcel. INT intarea Internet Area Working Group WG Grand BR SEC *** rats Remote ATtestation ProcedureS BOF FRIDAY, March 29, 2019 0900-1030 Morning Session I Grand BR ART *** core Constrained RESTful Environments WG Congress H 1 INT 6man IPv6 Maintenance WG Berlin/Brussels SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF 1050-1250 Morning Session II Berlin/Brussels INT ipwave IP Wireless Access in Vehicular = Environments WG Karlin 1/2 IRTF icnrg Information-Centric Networking Congress H 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Athens/Barcel. TSV taps Transport Services WG From nobody Sat Mar 2 16:11:37 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D271271FF for ; Sat, 2 Mar 2019 16:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NhyvYJClcgxr for ; Sat, 2 Mar 2019 16:11:34 -0800 (PST) Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (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 886C6124B0C for ; Sat, 2 Mar 2019 16:11:34 -0800 (PST) Received: from [10.183.0.14] ([167.160.116.54]) by :SMTPAUTH: with ESMTPSA id 0Ej7hVyhPBvYa0Ej7hZuyp; Sat, 02 Mar 2019 17:11:33 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: Date: Sat, 2 Mar 2019 16:11:32 -0800 Cc: Joe Hildebrand , Michael Richardson , cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6FC60F75-E182-47DD-B229-3B8908DD3474@island-resort.com> References: <81789050-5133-48B0-BEE7-4F1E0BBB4C06@island-resort.com> <40A3B694-80A4-4AD7-A2A6-C071C6E88D2D@tzi.org> <0A96C82A-85DB-411D-812D-5A3479A8EA87@mozilla.com> <052FFFD1-6145-4451-91A0-B07ED0AEC726@tzi.org> <9644.1551315204@localhost> <01396AC3-0EDE-4AEC-B60E-1274B9E66C52@mozilla.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfHvBL+PvWhtn9LCgDaI54oBbgUYEenXp2vmjGKutGL3IvBf2FJpuqpOKYq+7GQ9FOe8TNFekiudcIu7U/4klS2r9fQyIB06e/cWS31RM8wxb/vGlmAox fq45eWb4AXRx763SJWlOvvjzLPkgrsEDgKyOeAMS0Mpz/Kvatf2cgpm9SDmtMa7AoUAfSzH2Q++Eyry5ChUdTiawtQwdt7i9AJHmxPG4sPTNPttjvTMn16g/ MM0zxz1zsGS8vZ8PNLp0Ww== Archived-At: Subject: Re: [Cbor] correctness of implied top level array? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 00:11:36 -0000 > On Feb 28, 2019, at 12:46 PM, Carsten Bormann wrote: >=20 >> On Feb 28, 2019, at 20:23, Joe Hildebrand = wrote: >>=20 >>> On Feb 27, 2019, at 5:53 PM, Michael Richardson = wrote: >>>=20 >>> An alternative way to do the desired action (and bring this inside = of cbor) >>> would be an (indefinite?) array type that was specified to = concatenate. >>>=20 >>> I'm not really arguing for this, but I think it's worth knowing why = this >>> would be less good a thing. >>=20 >> It's an interesting idea. One of the reasons this didn't feel right = to me was that my initial take on indefinite-length arrays was to read = the whole array, growing memory as needed. I've moved on from that, but = would expect others to find themselves in a similar spot. >>=20 >> More interestingly though, there are times when I might want to use = an optional external length-framing approach, like embedding a single = CBOR data item in a WebSocket message. >=20 > It is hard for a format like CBOR to take in external length = information =E2=80=94 data items need to be self-delimiting *within* the = tree, so taking in that information at the top level would mean that a = different encoding would be needed there. >=20 > CBOR sequences are actually exactly that, for the specific case of a = top-level array. > So this is your =E2=80=9Carray type that was specified to = concatenate=E2=80=9D =E2=80=94 except that this cannot be used within a = CBOR data item ([[1, 2], [3, 4]] =E2=89=A0 [[1, 2, 3, 4]]), only right = on top. >=20 > Whether a single data item or a CBOR sequence is expected is indicated = by meta information, such as the Content-Type. We could define more = things like CBOR maps, CBOR strings (hey, we already have ct 0 for text = and 42 for bytes). This is becoming complicated quickly. >=20 > CBOR sequences stand out because they are often exactly what is needed = for streaming, and for flexible storage of partial streams in containers = that can then simply be concatenated. >=20 > Next stop: Getting a CDDL spec to define top-level sequences=E2=80=A6 = (Right now, we simply describe a top-level array and add = English-language information that this is to be encoded as a sequence. = Quite similar to how .cborseq works inside the spec.) When a decoder receives a CBOR data item, it always knows when it as = decoded the whole thing. Through the decoding is knows how many bytes it = needs. So one way to frame this up is by asking what should a decoder = do when it has got to the end of a data item.=20 With application/cbor, it is an error for there to be more bytes. With application/cbor-seq, further bytes are expected to be another data = item.=20 Another way to say this is that application/cbor is truly and fully = self-delimiting and application/cbor-seq is not. With = application/cbor-seq you rely on the unavailability of more bytes to = know it is the end. Maybe this answer=E2=80=99s Michaels question. If there was an implied = indefinite length array around all CBOR, then all CBOR would have to = either a) rely on something external like the end of a transmission or = b) have a CBOR break present to know it is the end. I don=E2=80=99t = think we want that. The net of it then seems that a protocol using CBOR should be clear = about whether it is application/cbor or application/cbor-seq. (Doesn=E2=80= =99t have to use MIME and MIME type and all that, just indicate some = how). LL From nobody Sun Mar 3 17:17:00 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B59130E6F; Sun, 3 Mar 2019 17:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 dn8u3q7Yviya; Sun, 3 Mar 2019 17:16:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DB71271FF; Sun, 3 Mar 2019 17:16:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8758638263; Sun, 3 Mar 2019 20:16:50 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 01AD0230F; Sun, 3 Mar 2019 20:16:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0047BC09; Sun, 3 Mar 2019 20:16:53 -0500 (EST) From: Michael Richardson To: cbor@ietf.org, core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cbor] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 01:16:59 -0000 --=-=-= Content-Type: text/plain I wonder if these two drafts wouldn't be better off in CBOR WG? draft-ietf-core-sid-05 YANG Schema Item iDentifier (SID) draft-ietf-core-yang-cbor-07 CBOR Encoding of Data Modeled with YANG Well, anything that would allow the SID to progress enough for the registries to be created so that they can be used. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlx8fIUACgkQgItw+93Q 3WUXJgf8D37wFwkWoPOTHw25FtIEGr/xd+/82MWq/at8Sc90RQ1Bs49zalaxSexD UmnXm7Ua1eXA1RkbJj3CtoBEkuMaYCTF1NnxGjoBqkPlPjFxxQnipZhfeac87+7N RrV4npcz8FaUjTjlvXiWFKa/q2qSfSATvVRl4Wn+ujQTkvmsAfDmgwDGbrEIDjgO lGTDJOHYXxw6g+SEPjDqSe7JS2iZfdp2Xpbe9FCwLnM//JYCB6fUhj72a+oWymGJ WPRMGTbv+8CxJ12x0+728t2au90bm4chz1I3JiquTbfAp2ksS08xNDDvya4aVJjD Q6ZcO7brh9HslS7HhR7pqO3HCuu6hQ== =KonB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 5 14:55:49 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896E01310FF; Tue, 5 Mar 2019 14:55:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <155182654151.27922.2215152083214187954@ietfa.amsl.com> Date: Tue, 05 Mar 2019 14:55:41 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-array-tags-03.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 22:55:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Typed Arrays Authors : Johnathan Roatch Carsten Bormann Filename : draft-ietf-cbor-array-tags-03.txt Pages : 14 Date : 2019-03-05 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as two additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-array-tags-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 Mar 5 14:58:08 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4020130DD3 for ; Tue, 5 Mar 2019 14:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 I0k942Mdgw7T for ; Tue, 5 Mar 2019 14:58:04 -0800 (PST) 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 E49AA1274D0 for ; Tue, 5 Mar 2019 14:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x25MvsFn003718 for ; Tue, 5 Mar 2019 23:57:59 +0100 (CET) Received: from client-0023.vpn.uni-bremen.de (client-0023.vpn.uni-bremen.de [134.102.107.23]) (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 44DXNf1s9qz1Bp8; Tue, 5 Mar 2019 23:57:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155182654151.27922.2215152083214187954@ietfa.amsl.com> Date: Tue, 5 Mar 2019 23:57:53 +0100 X-Mao-Original-Outgoing-Id: 573519471.243904-5d07c1370decb1f529859724eb5251c4 Content-Transfer-Encoding: quoted-printable Message-Id: <3F63EA31-F9A9-40FE-88E6-59C899061495@tzi.org> References: <155182654151.27922.2215152083214187954@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-array-tags-03.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 22:58:07 -0000 -03 reflects the fact that IANA has made the allocations. =46rom this author=E2=80=99s point of view, we are ready for WGLC. Gr=C3=BC=C3=9Fe, Carsten > On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Concise Binary Object Representation (CBOR) = Tags for Typed Arrays > Authors : Johnathan Roatch > Carsten Bormann > Filename : draft-ietf-cbor-array-tags-03.txt > Pages : 14 > Date : 2019-03-05 >=20 > Abstract: > The Concise Binary Object Representation (CBOR, RFC 7049) is a data > format whose design goals include the possibility of extremely small > code size, fairly small message size, and extensibility without the > need for version negotiation. >=20 > The present document makes use of this extensibility to define a > number of CBOR tags for typed arrays of numeric data, as well as two > additional tags for multi-dimensional and homogeneous arrays. It is > intended as the reference document for the IANA registration of the > CBOR tags defined. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-03 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Wed Mar 6 04:53:17 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158541292F1 for ; Wed, 6 Mar 2019 04:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=JJJWnovX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LJPumYBT 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 7rbOoMuKAopY for ; Wed, 6 Mar 2019 04:53:12 -0800 (PST) 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 5E7AE130ED4 for ; Wed, 6 Mar 2019 04:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551876790; x=1554468790; 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=N81fGZzayRYFQZXDpvSdkmWaM6iqO8EBZZB2Cf9NIr0=; b=JJJWnovXRfZyT8hf6ZI4dVmJXoNuAn/2cffU/N6DvW75uwQJHeZTYCXc5Grbw2+c 6Xhe2El0aSL6fgRROHwsxanUAolSFKZ/WddYROp+vLc63yFvQ3WBEaW6MIIfg1fl qv9e+8V72/qm7BkLaElniIpULqbQcdR4dsnA5aH4FTw=; X-AuditID: c1b4fb3a-5c9c29e00000672c-82-5c7fc2b68b92 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 36.42.26412.6B2CF7C5; Wed, 6 Mar 2019 13:53:10 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 13:53:09 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) 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; Wed, 6 Mar 2019 13:53:08 +0100 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=N81fGZzayRYFQZXDpvSdkmWaM6iqO8EBZZB2Cf9NIr0=; b=LJPumYBTqCnStEqt6M8o3G7hlO+qRJCovd4z+raLVVaSfqxfgKgzqu7q6UVeKc2h+0McuwSifo2E6hKYpYrla0MqhXNKI45YOHvn68/v++Vefd4fukCCRGd9Kx/8fiU4KqvhLCiZACjekLHzcWtRYOl362hvuaBkuroEwFuSs0M= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2906.eurprd07.prod.outlook.com (10.168.92.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.6; Wed, 6 Mar 2019 12:53:08 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58%10]) with mapi id 15.20.1709.005; Wed, 6 Mar 2019 12:53:07 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "draft-ietf-cbor-array-tags@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci1hcnJheS10YWdzLTAz?= Thread-Index: AQHU1BuL9SAZhhgYX0KbyJPWRVny1A== Date: Wed, 6 Mar 2019 12:53:07 +0000 Message-ID: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e31fe29-0c64-43e0-0ad2-08d6a232ae8b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2906; x-ms-traffictypediagnostic: HE1PR0701MB2906: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(346002)(376002)(136003)(199004)(189003)(450100002)(14444005)(256004)(86362001)(4326008)(6916009)(71200400001)(71190400001)(83716004)(68736007)(81156014)(1730700003)(81166006)(36756003)(33656002)(305945005)(25786009)(66066001)(82746002)(7736002)(5660300002)(8936002)(2351001)(106356001)(105586002)(102836004)(6506007)(53546011)(66574012)(99286004)(316002)(97736004)(2906002)(6512007)(14454004)(6306002)(26005)(3846002)(6116002)(186003)(478600001)(44832011)(2616005)(476003)(6436002)(6486002)(5640700003)(966005)(2501003)(486006)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2906; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DwvZUmQ6swPCf9pK1gCYp8SqAzaL538/k41YPrcvkO3x6A1vgdArTKx5sDr9In+vTtR0dEYNeoEqhCpiV8Kd40KTif09ALBoImV784sz6aNeY6J5mhJXDnFUdulGH6Sb2PKWU7gXNVXShcbZHS726kmDoA2/MZI/wbmAzh19PjdqekeWmJSUYj4lLVxw2Lew039X9qbqRpr3jeF76TN7zxy8gsNpD0UHY2DvUAdFMYikuH+70dMJm2fU0DFoCb/a8TV+EN72lULRK6ilr5icAElt20pY878U/57v/HAFvW/TSfoDavy5tHVWC9rpLH3+s0IPPzGcfpxVd+k+K6C9Y84ebV4jZyWfSN78wXcytxx9z9AYkDIQ3C/+AgFxv3+IRqifr8EufcQexM/cVKMjBui0VP/VGa3ZQ/g5bDIXA2w= Content-Type: text/plain; charset="utf-8" Content-ID: <589163D14A8ACB46BCA4114C768C0A6D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8e31fe29-0c64-43e0-0ad2-08d6a232ae8b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 12:53:07.8414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2906 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01SfyyUYRzfc+/78rKuPR2Xb8LpZP3iLrJFmZRV2mh1a+vWbHXxDsXh3svo B8qyMNEw7lKUW81xpatksXBUZKWdrMUfdRFqbVpj8qOWu0db/31+PZ/n+X73sJSokPFkk9Va TqNWpUidXGmd8okmsMWSG7d1cEgSqrtSRYc+bxpiIgXRBsOc4BA65hqewKUkZ3IaecQJ16Tr 33PSx3yzWnt7nPPQL0kRcmEBh0B187ygCLmyItyDoEPXTBMyg6B34YYTIfUCGB6YdTg0LqPA Mt9JEadSAL8XfjKEjCOYeN9G2ZudcDi8tU0xduyO/aCyonupi2UpfBi+dYTZZTccC2X9LYhE FJBnfLEcl8EDU7XAHqfxevhkFdtlId4FDa/maDtG2BumLzY6bqKwBwyP1QrIPBgM7QMUwWL4 OvqHIfl4eDdy1dleCdgXbI8Pkog3WGuLEcGx0L5Q5ZgE8AiCgYaeZSMAjHUdzgR7wuK9cprg NMifamZIpxeYLoWRszMM6O+UO94jwhzcNV1e7vEBY4mNJqEBCq6ZOlEZCtD/N4PesaFNcP+p nMjR8GX6FiJ4HVQU25z1jlWsgj7dGF2HGCMS8xzPpyYGB8s4TXI8z6epZWpOa0ZLH6Tr0cKO VtQ1sduCMIukK4SlbblxIkaVyWenWhCwlNRduL9pSRImqLLPcpq045ozKRxvQWtZWuohXBSt ihPhRJWWO81x6ZzmnytgXTzzUFRGeXv9+PYfN/sVwklzX/6GoH2SWOtoSYb/xlZ0PvRC6HDn vKxY6f9Rvrdgdk25uSTnpDpV0kdNakvNqj2NIW2F4hjFgYiE2+aYh4ruc/EvAz/7VR7Zckpy dNsEXfCssU4b5SP/wK9crRuc2KmsCfat9IrMfDOYpa631igNbq+lNJ+kCtpMaXjVXz6m31oc AwAA Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 12:53:16 -0000 Q0JPUiBXRywNCg0KVGhlIGNoYWlycyBiZWxpZXZlIHRoZSBhcnJheS10YWdzIGRvY3VtZW50IGlz IHJlYWR5IGZvciBXR0xDOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j Ym9yLWFycmF5LXRhZ3MtMDMNCg0KVGhlIFdHTEMgd2lsbCBlbmQgYnkgKjIwdGggb2YgTWFyY2gq LCBwbGVhc2UgbWFrZSBzdXJlIHRvIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCBiZWZv cmUgdGhlbi4NCg0KQmVzdCByZWdhcmRzLA0KRnJhbmNlc2NhICYgQmFycnkNCg0K77u/T24gMDUv MDMvMjAxOSwgMjM6NTgsICJDQk9SIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4iIDxjYm9y LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHppLm9yZz4gd3JvdGU6DQoNCiAg ICAtMDMgcmVmbGVjdHMgdGhlIGZhY3QgdGhhdCBJQU5BIGhhcyBtYWRlIHRoZSBhbGxvY2F0aW9u cy4NCiAgICANCiAgICBGcm9tIHRoaXMgYXV0aG9y4oCZcyBwb2ludCBvZiB2aWV3LCB3ZSBhcmUg cmVhZHkgZm9yIFdHTEMuDQogICAgDQogICAgR3LDvMOfZSwgQ2Fyc3Rlbg0KICAgIA0KICAgIA0K ICAgID4gT24gTWFyIDUsIDIwMTksIGF0IDIzOjU1LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg d3JvdGU6DQogICAgPiANCiAgICA+IA0KICAgID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAg ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0 IFJlcHJlc2VudGF0aW9uIE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zIFdHIG9mIHRoZSBJRVRG Lg0KICAgID4gDQogICAgPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQ29uY2lzZSBCaW5hcnkg T2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdzIGZvciBUeXBlZCBBcnJheXMNCiAgICA+ ICAgICAgICBBdXRob3JzICAgICAgICAgOiBKb2huYXRoYW4gUm9hdGNoDQogICAgPiAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2Fyc3RlbiBCb3JtYW5uDQogICAgPiAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1jYm9yLWFycmF5LXRhZ3MtMDMudHh0DQogICAgPiAJUGFnZXMgICAgICAg ICAgIDogMTQNCiAgICA+IAlEYXRlICAgICAgICAgICAgOiAyMDE5LTAzLTA1DQogICAgPiANCiAg ICA+IEFic3RyYWN0Og0KICAgID4gICBUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2Vu dGF0aW9uIChDQk9SLCBSRkMgNzA0OSkgaXMgYSBkYXRhDQogICAgPiAgIGZvcm1hdCB3aG9zZSBk ZXNpZ24gZ29hbHMgaW5jbHVkZSB0aGUgcG9zc2liaWxpdHkgb2YgZXh0cmVtZWx5IHNtYWxsDQog ICAgPiAgIGNvZGUgc2l6ZSwgZmFpcmx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZSwgYW5kIGV4dGVuc2li aWxpdHkgd2l0aG91dCB0aGUNCiAgICA+ICAgbmVlZCBmb3IgdmVyc2lvbiBuZWdvdGlhdGlvbi4N CiAgICA+IA0KICAgID4gICBUaGUgcHJlc2VudCBkb2N1bWVudCBtYWtlcyB1c2Ugb2YgdGhpcyBl eHRlbnNpYmlsaXR5IHRvIGRlZmluZSBhDQogICAgPiAgIG51bWJlciBvZiBDQk9SIHRhZ3MgZm9y IHR5cGVkIGFycmF5cyBvZiBudW1lcmljIGRhdGEsIGFzIHdlbGwgYXMgdHdvDQogICAgPiAgIGFk ZGl0aW9uYWwgdGFncyBmb3IgbXVsdGktZGltZW5zaW9uYWwgYW5kIGhvbW9nZW5lb3VzIGFycmF5 cy4gIEl0IGlzDQogICAgPiAgIGludGVuZGVkIGFzIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQgZm9y IHRoZSBJQU5BIHJlZ2lzdHJhdGlvbiBvZiB0aGUNCiAgICA+ICAgQ0JPUiB0YWdzIGRlZmluZWQu DQogICAgPiANCiAgICA+IA0KICAgID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWNib3ItYXJyYXktdGFncy8NCiAgICA+IA0KICAgID4gVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgID4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1hcnJheS10YWdzLTAzDQogICAgPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtY2Jvci1hcnJheS10YWdz LTAzDQogICAgPiANCiAgICA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWNib3ItYXJyYXktdGFncy0wMw0KICAgID4gDQogICAgPiANCiAgICA+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCiAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICA+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgPiANCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQogICAgPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQogICAgPiBJbnRlcm5l dC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KICAg ID4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCiAgICA+IA0K ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgDQoNCg== From nobody Thu Mar 7 17:04:02 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C513122C for ; Thu, 7 Mar 2019 17:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 3nwq_A8F5hKr for ; Thu, 7 Mar 2019 17:03:54 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 D23F9131132 for ; Thu, 7 Mar 2019 17:03:51 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id 199so15988483ljj.5 for ; Thu, 07 Mar 2019 17:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0PSMJhmz2Tz2P0BYKgQv515tLm+9LvzVvSSRSlBlBMI=; b=KPfPvLIvxbKIiPuG19d55aXdtikjsraW6xeC8gUVU/QA0a0laoPcgLsmjs6q4MNaar vGlJ1LzQjftFGWyUAdiT7rGbmArWC61fYIoM+xyRFp5yO/fLzZMVOcYagVir2ZHqSE/s B94nd+559OV913gWp0zLpYeBxLQ91fZwlvtH4= 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:content-transfer-encoding; bh=0PSMJhmz2Tz2P0BYKgQv515tLm+9LvzVvSSRSlBlBMI=; b=tkJG241fr9CrrOrBoJX5625gDicCpwLWuqR9xky+uY6KD+DqB8YmxI5cJCCPSE8Da3 dS0LAcN9d0jj0sOZF9LAVG/ju8Wb3hmP3TWuzEbbtI4Q7uCJ82DwPo3bX/XXGhjUlTA1 zIO4RR68zgXmOXwD6GGBboFQKi2yZcj45kjp9vMo3T9uEf3gl5ydS3TY7Ex2mzeNDZdo YD9+8jdzVAQkq8jCtUtJBHwvIsb90yXGgU+giJc7Qjx8zuzJSG5+bcvJWyjvSyP/zV4v 1Yj6NZ2FS+tm/nTABxPCScly1S0rbP5Ljtp7b7RBi/Rtu0ZabwYzffj/rNzfO1MNisiI 32VQ== X-Gm-Message-State: APjAAAW4SGBUk5RX6ceYJbKda/JjrfotA+l90Gwi+yy7JBNhZmZ8EqXg F5I6UdH9o+s7e1wAt/cPbQO932yYa/5Sv6jC6K7TLQ== X-Google-Smtp-Source: APXvYqyHX1ebJZg3pPB70dNjoDmMXZu2xmN+CyL81ATO8jwyowqM6PfD9v/JZKnN7AH4v0UrcbzdCtUEZMG+6Chx0JA= X-Received: by 2002:a2e:6a18:: with SMTP id f24mr7731548ljc.97.1552007029560; Thu, 07 Mar 2019 17:03:49 -0800 (PST) MIME-Version: 1.0 References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> In-Reply-To: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> From: Jeffrey Yasskin Date: Thu, 7 Mar 2019 17:03:37 -0800 Message-ID: To: Francesca Palombini Cc: "cbor@ietf.org" , "draft-ietf-cbor-array-tags@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 01:04:01 -0000 This generally looks good to me, with decreasing confidence as the document gets farther from the simple typed-array use case in its title. A couple comments below: 1. The document justifies itself with "performance" improvements, but I believe the tags also save the space overhead of encoding a type for each element or nested array. 2. It's not clear on the first reading that https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03#section-3.1 defines two different tags. I'd appreciate either a subsection for tag 1040 or parallel subsections for the two tags. 3. The definition of tag 40 ends with "Data in the Typed Array byte string =E2=80=A6", but the second sub-array doesn't need to be a Typed Arra= y. 4. The definition of tag 1040 starts with "Note" making it look non-normative. I'd rather have that paragraph define the meaning of the data item, like "The data item is interpreted the same as in tag 40 except that the second sub-array holds elements with the first dimension contiguous (column-major order)." 5. The reference to Section 7.1 of [TypedArrayUpdate] is out of date. 6. It's not clear to me that representing the source of the elements in a uint8 array is worth the confusion of re-using the is-little-endian bit. What's a use case? It exists in Javascript to define how assignment works, but one does not assign to CBOR data. 7. What's the use case for the homogenous array tag? Tags, in general, are mostly useful for generic parsers: do we have an example of one of those that's going to add a new set of homogenous array types for its consumers to have to check for? Jeffrey On Wed, Mar 6, 2019 at 4:53 AM Francesca Palombini wrote: > > CBOR WG, > > The chairs believe the array-tags document is ready for WGLC: https://too= ls.ietf.org/html/draft-ietf-cbor-array-tags-03 > > The WGLC will end by *20th of March*, please make sure to send your comme= nts to the list before then. > > Best regards, > Francesca & Barry > > =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" wrote: > > -03 reflects the fact that IANA has made the allocations. > > From this author=E2=80=99s point of view, we are ready for WGLC. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Concise Binary Object Representati= on Maintenance and Extensions WG of the IETF. > > > > Title : Concise Binary Object Representation (CBOR= ) Tags for Typed Arrays > > Authors : Johnathan Roatch > > Carsten Bormann > > Filename : draft-ietf-cbor-array-tags-03.txt > > Pages : 14 > > Date : 2019-03-05 > > > > Abstract: > > The Concise Binary Object Representation (CBOR, RFC 7049) is a da= ta > > format whose design goals include the possibility of extremely sm= all > > code size, fairly small message size, and extensibility without t= he > > need for version negotiation. > > > > The present document makes use of this extensibility to define a > > number of CBOR tags for typed arrays of numeric data, as well as = two > > additional tags for multi-dimensional and homogeneous arrays. It= is > > intended as the reference document for the IANA registration of t= he > > CBOR tags defined. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-03 > > > > > > Please note that it may take a couple of minutes from the time of s= ubmission > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Mar 7 19:16:05 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2F131133 for ; Thu, 7 Mar 2019 19:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4F3J5QXDsqD for ; Thu, 7 Mar 2019 19:16:00 -0800 (PST) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 D3E88131071 for ; Thu, 7 Mar 2019 19:16:00 -0800 (PST) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 25zKhrHggH8cN25zLhdm9T; Thu, 07 Mar 2019 20:15:59 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> Date: Thu, 7 Mar 2019 19:15:58 -0800 Cc: "cbor@ietf.org" , "draft-ietf-cbor-array-tags@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfGLQYxfkHmaiUWQHoQvpFlI0qR/lSBsjgU6sfbay11K8edkvVy0gVS/8AYwKpePQukJDw+xxA+cgcnIfZdOgb6F/XkOV9GsvnX5G2kRD4kV+KG7X4tG+ 8gYzOfgb7dnEdXbzgwzIhLNMxgT2V8jW1un1RfnbsqnVlUOhYCS1zg8bAcoHaKPfCmttmawL6d4qlWY+IoYntY7mj2G5jpHVau+NNatGTdO82XF7+XKWch+N JLbl9QmYNTpU9yzf3i4q6OsOi2qPogyX+Kgx2CcPpaE= Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 03:16:04 -0000 Comments in my usual vein=E2=80=A6 Because of the big/little endian option, it seems like this needs a = discussion about design protocols with it, about preferred encoding / = decoding and about interop. Probably it should say decoders should support both big and little and = the encoder can do what is natural. It seems like there might be an = option for both sides to support only one endianness, which will likely = often be little endian because it is common. LL > On Mar 6, 2019, at 4:53 AM, Francesca Palombini = wrote: >=20 > CBOR WG, >=20 > The chairs believe the array-tags document is ready for WGLC: = https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >=20 > The WGLC will end by *20th of March*, please make sure to send your = comments to the list before then. >=20 > Best regards, > Francesca & Barry >=20 > =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" = wrote: >=20 > -03 reflects the fact that IANA has made the allocations. >=20 > =46rom this author=E2=80=99s point of view, we are ready for WGLC. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: >>=20 >>=20 >> 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. >>=20 >> Title : Concise Binary Object Representation (CBOR) = Tags for Typed Arrays >> Authors : Johnathan Roatch >> Carsten Bormann >> Filename : draft-ietf-cbor-array-tags-03.txt >> Pages : 14 >> Date : 2019-03-05 >>=20 >> Abstract: >> The Concise Binary Object Representation (CBOR, RFC 7049) is a data >> format whose design goals include the possibility of extremely small >> code size, fairly small message size, and extensibility without the >> need for version negotiation. >>=20 >> The present document makes use of this extensibility to define a >> number of CBOR tags for typed arrays of numeric data, as well as two >> additional tags for multi-dimensional and homogeneous arrays. It is >> intended as the reference document for the IANA registration of the >> CBOR tags defined. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-03 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=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 Thu Mar 7 23:56:24 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE71312DE; Thu, 7 Mar 2019 23:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EHwlWVajkngG; Thu, 7 Mar 2019 23:56:12 -0800 (PST) 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 6538D131311; Thu, 7 Mar 2019 23:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x287u2Y0014445; Fri, 8 Mar 2019 08:56:07 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (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 44G0Dd6Bt5z1Bp8; Fri, 8 Mar 2019 08:56:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Fri, 8 Mar 2019 08:56:01 +0100 Cc: "cbor@ietf.org" , "draft-ietf-cbor-array-tags@ietf.org" X-Mao-Original-Outgoing-Id: 573724558.9582289-70bf69b9a33891193abf072d1c3b53f7 Content-Transfer-Encoding: quoted-printable Message-Id: References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 07:56:23 -0000 On Mar 8, 2019, at 02:03, Jeffrey Yasskin wrote: >=20 > This generally looks good to me, with decreasing confidence as the > document gets farther from the simple typed-array use case in its > title. A couple comments below: >=20 > 1. The document justifies itself with "performance" improvements, but > I believe the tags also save the space overhead of encoding a type for > each element or nested array. Potentially. (Depending on how many elements of the array are small = enough to benefit from even shorter encoding.) But that is indeed a = motivation. For this reader, space savings are part of =E2=80=9Cperformance=E2=80=9D. Do we have to be more explicit about that? > 2. It's not clear on the first reading that > https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03#section-3.1 > defines two different tags. I'd appreciate either a subsection for tag > 1040 or parallel subsections for the two tags. >=20 > 3. The definition of tag 40 ends with "Data in the Typed Array byte > string =E2=80=A6", but the second sub-array doesn't need to be a Typed = Array. >=20 > 4. The definition of tag 1040 starts with "Note" making it look > non-normative. I'd rather have that paragraph define the meaning of > the data item, like "The data item is interpreted the same as in tag > 40 except that the second sub-array holds elements with the first > dimension contiguous (column-major order)." >=20 > 5. The reference to Section 7.1 of [TypedArrayUpdate] is out of date. I believe these are all good opportunities for improvements. Will make = issues. > 6. It's not clear to me that representing the source of the elements > in a uint8 array is worth the confusion of re-using the > is-little-endian bit. What's a use case? It exists in Javascript to > define how assignment works, but one does not assign to CBOR data. It is not really where they came from, but how they are meant to be = processed further. So a JavaScript implementation would deserialize into a clamped array. > 7. What's the use case for the homogenous array tag? Tags, in general, > are mostly useful for generic parsers: do we have an example of one of > those that's going to add a new set of homogenous array types for its > consumers to have to check for? A generic decoder might lay out a more compact array of integers instead = of an array of CBOR data items when it sees this tag (and the first = element is an integer). I=E2=80=99m not sure there is an implementation out already that does = this. I think this becomes relevant at the encoder API only if there are = natural native types being fed in that are homogeneous (and the = application gives license to use the tag 41, but the typed array tags do = not apply). (Meta-comment: Maybe 40, 1040, and 41 should have gone into a separate = document. But it did feel expeditious to include them here.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 8 07:43:38 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB07124B91 for ; Fri, 8 Mar 2019 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eOyVl4BaK-uo for ; Fri, 8 Mar 2019 07:43:33 -0800 (PST) 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 A94FC120106 for ; Fri, 8 Mar 2019 07:43:33 -0800 (PST) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 2HelhPAWNlS8J2Hemh2nZP; Fri, 08 Mar 2019 08:43:33 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> Date: Fri, 8 Mar 2019 07:43:31 -0800 Cc: "cbor@ietf.org" , "draft-ietf-cbor-array-tags@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfBPtSIf8VQZXgQ1yKUP7lWLzIYP2Y9Y+hm2sDgBXu7rfEAV/eK9itDpIhf8BRxJP/2s8VAcWXrvg3HD79P3Li6nTyCS4/mwBEm0tLo0ZEbryV7dWRci0 4RWOzFy+oVIqoeJexwnlhm2Hbw6sWUHYXJWhjyXFcIAmr11RrzwjkzsDUQ81beVO9fs6LB4BgDU+vIDmSTLurZe1DSUvEcgvO4xkAPEEVRdVXCFt2X6iz+j5 mBn2u/zCWKNmLUErfZpFKKqzkNTfFbF2RuwFzO8I00g= Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 15:43:36 -0000 In addition to what I said before, a deterministic encoding should be = specified (formerly known as canonical) in the specification and that = should probably be network / big endian. To go on a bit more about detailed implementation... In a native implementation there is also memory access alignment issue = on the decode side, but not the encode side. Memory alignment is an = issue on some Arm CPUs, though not on Intel CPUs as far as I know. So on = some Arm CPUs, it won=E2=80=99t be possible to just return pointers to = the bytes that came off the wire. Because non-string and non-aggregate = CBOR data items can be 1, 2, 3, 5 and 9 bytes long, there can be no = guarantee of alignment of the incoming encoded CBOR bytes.=20 A portable decoder implementation will have to allocate aligned memory = for the array and copy it. The decoder can byte-swap while it is copying = so it lines up OK with the decoder having to do most of the work to = achieve interop. There=E2=80=99s no alignment issue on the encode side. The only other thing I=E2=80=99ve encountered in CBOR that needs copying = of data is indefinite length strings.=20 LL > On Mar 7, 2019, at 7:15 PM, Laurence Lundblade = wrote: >=20 > Comments in my usual vein=E2=80=A6 >=20 > Because of the big/little endian option, it seems like this needs a = discussion about design protocols with it, about preferred encoding / = decoding and about interop. >=20 > Probably it should say decoders should support both big and little and = the encoder can do what is natural. It seems like there might be an = option for both sides to support only one endianness, which will likely = often be little endian because it is common. >=20 > LL >=20 >=20 >> On Mar 6, 2019, at 4:53 AM, Francesca Palombini = wrote: >>=20 >> CBOR WG, >>=20 >> The chairs believe the array-tags document is ready for WGLC: = https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >>=20 >> The WGLC will end by *20th of March*, please make sure to send your = comments to the list before then. >>=20 >> Best regards, >> Francesca & Barry >>=20 >> =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" = wrote: >>=20 >> -03 reflects the fact that IANA has made the allocations. >>=20 >> =46rom this author=E2=80=99s point of view, we are ready for WGLC. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : Concise Binary Object Representation (CBOR) = Tags for Typed Arrays >>> Authors : Johnathan Roatch >>> Carsten Bormann >>> Filename : draft-ietf-cbor-array-tags-03.txt >>> Pages : 14 >>> Date : 2019-03-05 >>>=20 >>> Abstract: >>> The Concise Binary Object Representation (CBOR, RFC 7049) is a data >>> format whose design goals include the possibility of extremely small >>> code size, fairly small message size, and extensibility without the >>> need for version negotiation. >>>=20 >>> The present document makes use of this extensibility to define a >>> number of CBOR tags for typed arrays of numeric data, as well as two >>> additional tags for multi-dimensional and homogeneous arrays. It is >>> intended as the reference document for the IANA registration of the >>> CBOR tags defined. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >>> https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-03 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>=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 From nobody Sat Mar 9 11:18:20 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9D124B91; Sat, 9 Mar 2019 11:18:18 -0800 (PST) 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 514m-lUx6n07; Sat, 9 Mar 2019 11:18:16 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70412426E; Sat, 9 Mar 2019 11:18:16 -0800 (PST) Received: from Jude (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 9 Mar 2019 11:18:10 -0800 From: Jim Schaad To: CC: References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> In-Reply-To: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> Date: Sat, 9 Mar 2019 11:18:06 -0800 Message-ID: <033701d4d6ac$d4b1fb60$7e15f220$@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: AQJDckXT1PNyaRbuIeGp9sN/08XZzKUlaSUA Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:18:19 -0000 Here is my WGLC review of the document. 1. In section 2.1 I had a brief moment of frisson on the use of the = term binary16 rather than float16 in Table 1. There is no need to = change it, I just was momentarily jolted. 2. In section 2.1 - Slightly odd to say that ll is lsb as it is two = bits long. No need to change it, but the RSE may notice it. 3. In section 2.1 - suggest s/Only the big endian variant is used./Only = the big endian variant is assigned a tag./ 4. In section 2.1 - There should be a note about the fate of the tags = that would be . Are they reserved or open for = assignment. 5. In section 2.1 - After reading the last sentence, I am no longer sure = what the fate of the 8-bit little endian tags are. It would appear that = they are being assigned from this paragraph. 6. In section 3 - It would make thing clearer if the description here = noted that Homogeneous Arrays are one-dimensional array. 7. There should be a security consideration in terms of the Homogeneous = type in terms of a na=C3=AFve implementation. The description contains = the text "The element type of the array is thus determined by the = application type of the first array element" Since it is not clear that = this choosing of the application type does or does not still require = that each element of the array be correctly type checked while reading = the output is done, this requirement needs to be highlighted in the = event that an element which does not following the homogeneous type = follows. Additionally, it might need to be noted that this does not = imply that the same elements are going to be present in each element in = the array. Jim From nobody Sat Mar 9 11:39:40 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F8130EA4; Sat, 9 Mar 2019 11:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fECpTlINtonN; Sat, 9 Mar 2019 11:39:22 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25572130EE9; Sat, 9 Mar 2019 11:39:19 -0800 (PST) Received: from Jude (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 9 Mar 2019 11:39:11 -0800 From: Jim Schaad To: 'Laurence Lundblade' , 'Francesca Palombini' CC: , References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> In-Reply-To: <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> Date: Sat, 9 Mar 2019 11:39:07 -0800 Message-ID: <033d01d4d6af$c48be3b0$4da3ab10$@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: AQJDckXT1PNyaRbuIeGp9sN/08XZzALTp86QAZld6++lAxE/gA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:39:38 -0000 > -----Original Message----- > From: CBOR On Behalf Of Laurence Lundblade > Sent: Friday, March 8, 2019 7:44 AM > To: Francesca Palombini > Cc: cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org > Subject: Re: [Cbor] =F0=9F=94=94 WGLC on draft-ietf-cbor-array-tags-03 >=20 > In addition to what I said before, a deterministic encoding should be > specified (formerly known as canonical) in the specification and that = should > probably be network / big endian. I don't know that I agree with this. Most of the machines that I am = working with today are little endian machines, from that point of view = if such a thing is done then little endian makes more sense. However = the fact that these are different tags implies that there is no need to = have a deterministic encoding for this. The encoding is going to be = deterministic based on which endianness is chosen and that is machine or = program specific. I would expect that many implementations would not = bother with the big endian encode and might not do the decode as they = would be very rarely found. >=20 > To go on a bit more about detailed implementation... >=20 > In a native implementation there is also memory access alignment issue = on > the decode side, but not the encode side. Memory alignment is an issue = on > some Arm CPUs, though not on Intel CPUs as far as I know. So on some = Arm > CPUs, it won=E2=80=99t be possible to just return pointers to the = bytes that came off > the wire. Because non-string and non-aggregate CBOR data items can be = 1, 2, > 3, 5 and 9 bytes long, there can be no guarantee of alignment of the = incoming > encoded CBOR bytes. > A portable decoder implementation will have to allocate aligned memory = for > the array and copy it. The decoder can byte-swap while it is copying = so it lines > up OK with the decoder having to do most of the work to achieve = interop. I am confused here about what you are saying here. I think you mean = that returning a pointer to data block in the encoded structure may be a = problem if it is not aligned, but if that is what you are saying I = really don't understand that from the above text. Jim >=20 > There=E2=80=99s no alignment issue on the encode side. >=20 > The only other thing I=E2=80=99ve encountered in CBOR that needs = copying of data is > indefinite length strings. That depends on the internal structure of binary data as well. It may = also need to be copied to get correct alignment. >=20 > LL >=20 >=20 >=20 > > On Mar 7, 2019, at 7:15 PM, Laurence Lundblade = > wrote: > > > > Comments in my usual vein=E2=80=A6 > > > > Because of the big/little endian option, it seems like this needs a = discussion > about design protocols with it, about preferred encoding / decoding = and > about interop. > > > > Probably it should say decoders should support both big and little = and the > encoder can do what is natural. It seems like there might be an option = for > both sides to support only one endianness, which will likely often be = little > endian because it is common. > > > > LL > > > > > >> On Mar 6, 2019, at 4:53 AM, Francesca Palombini > wrote: > >> > >> CBOR WG, > >> > >> The chairs believe the array-tags document is ready for WGLC: > >> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > >> > >> The WGLC will end by *20th of March*, please make sure to send your > comments to the list before then. > >> > >> Best regards, > >> Francesca & Barry > >> > >> =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" = bounces@ietf.org on behalf of cabo@tzi.org> wrote: > >> > >> -03 reflects the fact that IANA has made the allocations. > >> > >> From this author=E2=80=99s point of view, we are ready for WGLC. > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> > >>> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>> This draft is a work item of the Concise Binary Object = Representation > Maintenance and Extensions WG of the IETF. > >>> > >>> Title : Concise Binary Object Representation (CBOR) = Tags for > Typed Arrays > >>> Authors : Johnathan Roatch > >>> Carsten Bormann > >>> Filename : draft-ietf-cbor-array-tags-03.txt > >>> Pages : 14 > >>> Date : 2019-03-05 > >>> > >>> Abstract: > >>> The Concise Binary Object Representation (CBOR, RFC 7049) is a = data > >>> format whose design goals include the possibility of extremely = small > >>> code size, fairly small message size, and extensibility without = the > >>> need for version negotiation. > >>> > >>> The present document makes use of this extensibility to define a > >>> number of CBOR tags for typed arrays of numeric data, as well as = two > >>> additional tags for multi-dimensional and homogeneous arrays. It = is > >>> intended as the reference document for the IANA registration of = the > >>> CBOR tags defined. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > >>> = https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-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/ > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > > 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 Sat Mar 9 12:46:06 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811C127964 for ; Sat, 9 Mar 2019 12:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2yNM_9aik8Hx for ; Sat, 9 Mar 2019 12:46:02 -0800 (PST) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.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 ECD02127598 for ; Sat, 9 Mar 2019 12:46:01 -0800 (PST) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 2ir1hZ6LJnjLw2ir2hAOZl; Sat, 09 Mar 2019 13:46:01 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Laurence Lundblade In-Reply-To: <033d01d4d6af$c48be3b0$4da3ab10$@augustcellars.com> Date: Sat, 9 Mar 2019 12:45:59 -0800 Cc: Francesca Palombini , cbor@ietf.org, draft-ietf-cbor-array-tags@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> <033d01d4d6af$c48be3b0$4da3ab10$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfG57VViO1B/LKucx9eFDzZs153zrYmlgcHMVPrAMqG0LfrNVus2/gZIL9e7dtffS7G9x2E23fI1VUy7wIUJIif4DnLq0/0nPlUcMdzCRzGDcQA3xZHd+ ffkgm2ktaGXEk3TAT7YUW8jWgmLaLdrTIyg9A1k0xTZVwIoqKUGFytJgpJtmienvXQuMy0ayjRfuvsR0/sAyVZ3vqy4AAVhi2y45MvwDXB4Jjs0/HlBQBkbg Eao31QfTUGUN4niR/mvQscZ4Aa18OXsOtvRnMbFHuQzGzVVOHzjRINSJVi2Dn52195ReB2+HGpaotQIyynYI1g== Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 20:46:05 -0000 Hi Jim, > On Mar 9, 2019, at 11:39 AM, Jim Schaad = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: CBOR On Behalf Of Laurence Lundblade >> Sent: Friday, March 8, 2019 7:44 AM >> To: Francesca Palombini >> Cc: cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org >> Subject: Re: [Cbor] =F0=9F=94=94 WGLC on = draft-ietf-cbor-array-tags-03 >>=20 >> In addition to what I said before, a deterministic encoding should be >> specified (formerly known as canonical) in the specification and that = should >> probably be network / big endian. >=20 > I don't know that I agree with this. Most of the machines that I am = working with today are little endian machines, from that point of view = if such a thing is done then little endian makes more sense. However = the fact that these are different tags implies that there is no need to = have a deterministic encoding for this. The encoding is going to be = deterministic based on which endianness is chosen and that is machine or = program specific. I would expect that many implementations would not = bother with the big endian encode and might not do the decode as they = would be very rarely found. My understanding of deterministic encoding is something like this =E2=80=94= For a given input, say the array [100,200,300,400], two independently = written encoders should produce *exactly* the same encoded bits. A = general test vector for this array would work correctly for both an = encoder written in the Foo language on a big endian machine and the Bar = language on a little endian machine. There is also the COSE Sig_structure and similar use cases. Some encoded = CBOR that is not transmitted must be constructed by the sender and = receiver and it has to be exactly correct because it is being hashed. If the implementor gets to choose big / little endian as they wish, we = don=E2=80=99t get deterministic encoding like that.=20 Personally, I don=E2=80=99t think deterministic encoding is that useful = and would probably be happy seeing it go away completely. I suggested = that in Bangkok, and the response was that some people (who weren=E2=80=99= t in the room) really care about it. Here, I=E2=80=99m just pointing = out, that if we=E2=80=99re doing deterministic encoding, we should do it = for array tags too. I think interop is the bigger issue here (and deterministic encoding !=3D = interop) . If everyone does what is natural for their CPU, we mostly = have interop because little endian is the most common, but interop is = not guaranteed because big endian CPUs exist. I think the spec should be = tighter and should spell out what is to be done by a generic = encode/decoder so that interop is guaranteed. Maybe frame it up in three = options: 1) Specify rules for preferred encoders and decoders like this: decoders = should support both big and little endian. Encoders should do network = byte order, but can choose as they wish. =20 2) Just outright say tagged arrays are always little endian. Drop the = tagging of little vs big. 3) Just outright say tagged arrays are always network big endian. Drop = the tagging of little vs big. If most CPUs were big endian, the obvious choice would be 3). The = problem with 2) is the mixed message where some parts of CBOR are big = endian and other are little. The problem with 1) is that it is more = complicated and implementors are more likely to get it wrong. Personally, I kind of like 2). >=20 >>=20 >> To go on a bit more about detailed implementation... >>=20 >> In a native implementation there is also memory access alignment = issue on >> the decode side, but not the encode side. Memory alignment is an = issue on >> some Arm CPUs, though not on Intel CPUs as far as I know. So on some = Arm >> CPUs, it won=E2=80=99t be possible to just return pointers to the = bytes that came off >> the wire. Because non-string and non-aggregate CBOR data items can be = 1, 2, >> 3, 5 and 9 bytes long, there can be no guarantee of alignment of the = incoming >> encoded CBOR bytes. >> A portable decoder implementation will have to allocate aligned = memory for >> the array and copy it. The decoder can byte-swap while it is copying = so it lines >> up OK with the decoder having to do most of the work to achieve = interop. >=20 > I am confused here about what you are saying here. I think you mean = that returning a pointer to data block in the encoded structure may be a = problem if it is not aligned, but if that is what you are saying I = really don't understand that from the above text. Yes, that is what I=E2=80=99m saying. Sorry I wasn=E2=80=99t more clear. >=20 > Jim >=20 >>=20 >> There=E2=80=99s no alignment issue on the encode side. >>=20 >> The only other thing I=E2=80=99ve encountered in CBOR that needs = copying of data is >> indefinite length strings. >=20 > That depends on the internal structure of binary data as well. It may = also need to be copied to get correct alignment. For a rich, complete and true generic decoder, the obvious thing to do = with array tags is return an array of integers in the native CPU format. = If the CPU doesn=E2=80=99t support unaligned access, then that array of = integers must be aligned. I think the contents of a binary string are different. First of all, if = it has internal structure, they should have encoded the internals with = CBOR in the first place. :-). Second, there is nothing in the CBOR type = information that tells a generic CBOR encoder if it needs to be aligned = or not. I would think most of the time it does not, so aligning by = default would be wasteful. All that said, I don=E2=80=99t see that alignment has any affect on the = text in the draft. The main issue for me is the interop issue that = arrises from the option to transmit either big or little endian. LL >=20 >=20 >>=20 >> LL >>=20 >>=20 >>=20 >>> On Mar 7, 2019, at 7:15 PM, Laurence Lundblade = >> wrote: >>>=20 >>> Comments in my usual vein=E2=80=A6 >>>=20 >>> Because of the big/little endian option, it seems like this needs a = discussion >> about design protocols with it, about preferred encoding / decoding = and >> about interop. >>>=20 >>> Probably it should say decoders should support both big and little = and the >> encoder can do what is natural. It seems like there might be an = option for >> both sides to support only one endianness, which will likely often be = little >> endian because it is common. >>>=20 >>> LL >>>=20 >>>=20 >>>> On Mar 6, 2019, at 4:53 AM, Francesca Palombini >> wrote: >>>>=20 >>>> CBOR WG, >>>>=20 >>>> The chairs believe the array-tags document is ready for WGLC: >>>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >>>>=20 >>>> The WGLC will end by *20th of March*, please make sure to send your >> comments to the list before then. >>>>=20 >>>> Best regards, >>>> Francesca & Barry >>>>=20 >>>> =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten Bormann" = > bounces@ietf.org on behalf of cabo@tzi.org> wrote: >>>>=20 >>>> -03 reflects the fact that IANA has made the allocations. >>>>=20 >>>> =46rom this author=E2=80=99s point of view, we are ready for WGLC. >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>>=20 >>>>> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Title : Concise Binary Object Representation (CBOR) = Tags for >> Typed Arrays >>>>> Authors : Johnathan Roatch >>>>> Carsten Bormann >>>>> Filename : draft-ietf-cbor-array-tags-03.txt >>>>> Pages : 14 >>>>> Date : 2019-03-05 >>>>>=20 >>>>> Abstract: >>>>> The Concise Binary Object Representation (CBOR, RFC 7049) is a = data >>>>> format whose design goals include the possibility of extremely = small >>>>> code size, fairly small message size, and extensibility without = the >>>>> need for version negotiation. >>>>>=20 >>>>> The present document makes use of this extensibility to define a >>>>> number of CBOR tags for typed arrays of numeric data, as well as = two >>>>> additional tags for multi-dimensional and homogeneous arrays. It = is >>>>> intended as the reference document for the IANA registration of = the >>>>> CBOR tags defined. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-03 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-03 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>=20 >>>>=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 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 >=20 From nobody Sat Mar 9 14:07:42 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DE71277D9; Sat, 9 Mar 2019 14:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YVQM_HVlvbYq; Sat, 9 Mar 2019 14:07:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3198812705F; Sat, 9 Mar 2019 14:07:36 -0800 (PST) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 9 Mar 2019 14:07:26 -0800 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Francesca Palombini' , , References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> <033d01d4d6af$c48be3b0$4da3ab10$@augustcellars.com> In-Reply-To: Date: Sat, 9 Mar 2019 14:07:22 -0800 Message-ID: <034701d4d6c4$7a4f52e0$6eedf8a0$@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: AQJDckXT1PNyaRbuIeGp9sN/08XZzALTp86QAZld6+8BpCWg/gJzCcw6pOKCIAA= Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 22:07:40 -0000 > -----Original Message----- > From: Laurence Lundblade > Sent: Saturday, March 9, 2019 12:46 PM > To: Jim Schaad > Cc: Francesca Palombini ; > cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org > Subject: Re: [Cbor] =F0=9F=94=94 WGLC on draft-ietf-cbor-array-tags-03 >=20 > Hi Jim, >=20 > > On Mar 9, 2019, at 11:39 AM, Jim Schaad = wrote: > > > > > > > >> -----Original Message----- > >> From: CBOR On Behalf Of Laurence Lundblade > >> Sent: Friday, March 8, 2019 7:44 AM > >> To: Francesca Palombini > >> Cc: cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org > >> Subject: Re: [Cbor] =F0=9F=94=94 WGLC on = draft-ietf-cbor-array-tags-03 > >> > >> In addition to what I said before, a deterministic encoding should = be > >> specified (formerly known as canonical) in the specification and = that > >> should probably be network / big endian. > > > > I don't know that I agree with this. Most of the machines that I am = working > with today are little endian machines, from that point of view if such = a thing is > done then little endian makes more sense. However the fact that these = are > different tags implies that there is no need to have a deterministic = encoding > for this. The encoding is going to be deterministic based on which > endianness is chosen and that is machine or program specific. I would = expect > that many implementations would not bother with the big endian encode > and might not do the decode as they would be very rarely found. >=20 > My understanding of deterministic encoding is something like this = =E2=80=94 For a > given input, say the array [100,200,300,400], two independently = written > encoders should produce *exactly* the same encoded bits. A general = test > vector for this array would work correctly for both an encoder written = in the > Foo language on a big endian machine and the Bar language on a little = endian > machine. >=20 > There is also the COSE Sig_structure and similar use cases. Some = encoded > CBOR that is not transmitted must be constructed by the sender and = receiver > and it has to be exactly correct because it is being hashed. >=20 > If the implementor gets to choose big / little endian as they wish, we = don=E2=80=99t > get deterministic encoding like that. >=20 > Personally, I don=E2=80=99t think deterministic encoding is that = useful and would > probably be happy seeing it go away completely. I suggested that in = Bangkok, > and the response was that some people (who weren=E2=80=99t in the = room) really > care about it. Here, I=E2=80=99m just pointing out, that if = we=E2=80=99re doing deterministic > encoding, we should do it for array tags too. >=20 >=20 > I think interop is the bigger issue here (and deterministic encoding = !=3D > interop) . If everyone does what is natural for their CPU, we mostly = have > interop because little endian is the most common, but interop is not > guaranteed because big endian CPUs exist. I think the spec should be = tighter > and should spell out what is to be done by a generic encode/decoder so = that > interop is guaranteed. Maybe frame it up in three options: >=20 > 1) Specify rules for preferred encoders and decoders like this: = decoders > should support both big and little endian. Encoders should do network = byte > order, but can choose as they wish. >=20 > 2) Just outright say tagged arrays are always little endian. Drop the = tagging of > little vs big. >=20 > 3) Just outright say tagged arrays are always network big endian. Drop = the > tagging of little vs big. >=20 > If most CPUs were big endian, the obvious choice would be 3). The = problem > with 2) is the mixed message where some parts of CBOR are big endian = and > other are little. The problem with 1) is that it is more complicated = and > implementors are more likely to get it wrong. >=20 > Personally, I kind of like 2). Given that I don't care about deterministic mapping from data model to = CBOR encoding, I don't see an issue here. I will always get the same = CBOR bytes given the same binary data.=20 >=20 >=20 > > > >> > >> To go on a bit more about detailed implementation... > >> > >> In a native implementation there is also memory access alignment > >> issue on the decode side, but not the encode side. Memory alignment > >> is an issue on some Arm CPUs, though not on Intel CPUs as far as I > >> know. So on some Arm CPUs, it won=E2=80=99t be possible to just = return > >> pointers to the bytes that came off the wire. Because non-string = and > >> non-aggregate CBOR data items can be 1, 2, 3, 5 and 9 bytes long, > >> there can be no guarantee of alignment of the incoming encoded CBOR > bytes. > >> A portable decoder implementation will have to allocate aligned > >> memory for the array and copy it. The decoder can byte-swap while = it > >> is copying so it lines up OK with the decoder having to do most of = the > work to achieve interop. > > > > I am confused here about what you are saying here. I think you mean = that > returning a pointer to data block in the encoded structure may be a = problem > if it is not aligned, but if that is what you are saying I really = don't understand > that from the above text. >=20 > Yes, that is what I=E2=80=99m saying. Sorry I wasn=E2=80=99t more = clear. I would agree this is a valid issue to highlight. Jim >=20 > > > > Jim > > > >> > >> There=E2=80=99s no alignment issue on the encode side. > >> > >> The only other thing I=E2=80=99ve encountered in CBOR that needs = copying of > >> data is indefinite length strings. > > > > That depends on the internal structure of binary data as well. It = may also > need to be copied to get correct alignment. >=20 > For a rich, complete and true generic decoder, the obvious thing to do = with > array tags is return an array of integers in the native CPU format. If = the CPU > doesn=E2=80=99t support unaligned access, then that array of integers = must be > aligned. >=20 > I think the contents of a binary string are different. First of all, = if it has internal > structure, they should have encoded the internals with CBOR in the = first > place. :-). Second, there is nothing in the CBOR type information that = tells a > generic CBOR encoder if it needs to be aligned or not. I would think = most of > the time it does not, so aligning by default would be wasteful. >=20 >=20 > All that said, I don=E2=80=99t see that alignment has any affect on = the text in the draft. > The main issue for me is the interop issue that arrises from the = option to > transmit either big or little endian. >=20 > LL >=20 >=20 > > > > > >> > >> LL > >> > >> > >> > >>> On Mar 7, 2019, at 7:15 PM, Laurence Lundblade > >>> > >> wrote: > >>> > >>> Comments in my usual vein=E2=80=A6 > >>> > >>> Because of the big/little endian option, it seems like this needs = a > >>> discussion > >> about design protocols with it, about preferred encoding / decoding > >> and about interop. > >>> > >>> Probably it should say decoders should support both big and little > >>> and the > >> encoder can do what is natural. It seems like there might be an > >> option for both sides to support only one endianness, which will > >> likely often be little endian because it is common. > >>> > >>> LL > >>> > >>> > >>>> On Mar 6, 2019, at 4:53 AM, Francesca Palombini > >> wrote: > >>>> > >>>> CBOR WG, > >>>> > >>>> The chairs believe the array-tags document is ready for WGLC: > >>>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > >>>> > >>>> The WGLC will end by *20th of March*, please make sure to send = your > >> comments to the list before then. > >>>> > >>>> Best regards, > >>>> Francesca & Barry > >>>> > >>>> =EF=BB=BFOn 05/03/2019, 23:58, "CBOR on behalf of Carsten = Bormann" >> bounces@ietf.org on behalf of cabo@tzi.org> wrote: > >>>> > >>>> -03 reflects the fact that IANA has made the allocations. > >>>> > >>>> From this author=E2=80=99s point of view, we are ready for WGLC. > >>>> > >>>> Gr=C3=BC=C3=9Fe, Carsten > >>>> > >>>> > >>>>> On Mar 5, 2019, at 23:55, internet-drafts@ietf.org wrote: > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the on-line = Internet-Drafts > >> directories. > >>>>> This draft is a work item of the Concise Binary Object > >>>>> Representation > >> Maintenance and Extensions WG of the IETF. > >>>>> > >>>>> Title : Concise Binary Object Representation = (CBOR) Tags for > >> Typed Arrays > >>>>> Authors : Johnathan Roatch > >>>>> Carsten Bormann > >>>>> Filename : draft-ietf-cbor-array-tags-03.txt > >>>>> Pages : 14 > >>>>> Date : 2019-03-05 > >>>>> > >>>>> Abstract: > >>>>> The Concise Binary Object Representation (CBOR, RFC 7049) is a > >>>>> data format whose design goals include the possibility of > >>>>> extremely small code size, fairly small message size, and > >>>>> extensibility without the need for version negotiation. > >>>>> > >>>>> The present document makes use of this extensibility to define a > >>>>> number of CBOR tags for typed arrays of numeric data, as well as > >>>>> two additional tags for multi-dimensional and homogeneous = arrays. > >>>>> It is intended as the reference document for the IANA = registration > >>>>> of the CBOR tags defined. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-cbor-array-tags/ > >>>>> > >>>>> There are also htmlized versions available at: > >>>>> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03 > >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-cbor-array-tags-0 > >>>>> 3 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-array-tags-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/ > >>>>> > >>>>> _______________________________________________ > >>>>> I-D-Announce mailing list > >>>>> I-D-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> _______________________________________________ > >>> CBOR mailing list > >>> CBOR@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cbor > >> > >> _______________________________________________ > >> CBOR mailing list > >> CBOR@ietf.org > >> https://www.ietf.org/mailman/listinfo/cbor > > > > From nobody Tue Mar 12 01:35:57 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A031F130EFA for ; Tue, 12 Mar 2019 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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=fqHSG0h1; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Tsd35vlL 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 IbYSieWM6qTD for ; Tue, 12 Mar 2019 01:35:52 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C8C75130EEE for ; Tue, 12 Mar 2019 01:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552379748; x=1554971748; 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=yWmF1RUeD8Mohoq3dOB9Jy/22/dTVjruRSpp3c3MYsg=; b=fqHSG0h1q+M4IZeHMpwXN0xm68K3u1PnXBg7kuhdvAX7Mv6TxsRogMKCwapb/+kW 59WHAGtTx8NN06taf86T81/+qXJdW08pmCJ6Q5SGaKZzj2sVd9ii6M/sAtY4mgWS zQpvUz4ZeSco9D20QUykptwXTdgy3MdpAte7Z+v3Zy0=; X-AuditID: c1b4fb30-fabff7000000355c-a2-5c876f64a84f Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.FC.13660.46F678C5; Tue, 12 Mar 2019 09:35:48 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 12 Mar 2019 09:35:48 +0100 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 12 Mar 2019 09:35:48 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) 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; Tue, 12 Mar 2019 09:35:48 +0100 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=yWmF1RUeD8Mohoq3dOB9Jy/22/dTVjruRSpp3c3MYsg=; b=Tsd35vlLdRQGexUXIfau13LqOH5GC7FNFc1bY10Bf7gsEDH073CwfRz91ywEhFBoVBdHFxhvLhM3Ou0CjZ8aH99GVrZyoiNIL87m+eoS6WUOxhDPyb+h40FkGxfOqbul1YVj7l6cZWcGCeDsjKi/WI7sHbgLeYVO6TF8qblgpWY= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2233.eurprd07.prod.outlook.com (10.168.29.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Tue, 12 Mar 2019 08:35:47 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58%10]) with mapi id 15.20.1709.011; Tue, 12 Mar 2019 08:35:47 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot request for IETF 104 Thread-Index: AQHU2K6XOVncETbstUWlLwJrndh/tA== Date: Tue, 12 Mar 2019 08:35:47 +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.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6aa697b-40d2-476d-ce85-08d6a6c5b999 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2233; x-ms-traffictypediagnostic: HE1PR0701MB2233: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(376002)(346002)(39860400002)(53754006)(199004)(189003)(6436002)(2351001)(71190400001)(33656002)(186003)(86362001)(2501003)(81156014)(83716004)(71200400001)(81166006)(36756003)(8676002)(476003)(2616005)(1730700003)(5660300002)(25786009)(5640700003)(44832011)(3846002)(6116002)(486006)(4326008)(82746002)(256004)(14444005)(68736007)(6916009)(97736004)(7736002)(2906002)(305945005)(105586002)(966005)(106356001)(14454004)(450100002)(26005)(99286004)(53936002)(478600001)(6306002)(102836004)(6512007)(66066001)(6346003)(316002)(6506007)(8936002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2233; H:HE1PR0701MB2746.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cREbxVWXYuzWH/U+vUVPbhpTbVqy/enVs8HjknZjSnrTBJyqMfistJUkvZfUQje/hfpFxvj0xd1RmBMNW0CVa2VHEuyWPvCvNa9zfmaZZodlJ2TMujLZQsYwGRE7YJ3r7xyg1IteE3vfDws5phR+YAcu/WzIRb6/GPLLtymA4VkJGxFovAtqwXQX0ro4IbIl48AZXV/ltrvSTVHcKUnWyoaQVL/xeRNOW3s57DSocgWKxLnmbXmTNyXF9rIuvUM0qgT8u+qaZjyFlB+na16HRhFQZeLDKk/f427FKfgDM3jFlsPd04I/Hbe/FwGX04aFKG8gvz2hcGSg4F+hRj2I5UEgAh+FYAii99nDepbJeA+3fARlEZi1Q8+u5zt03ZNFgoqJBSRTkXHBzrcqfotK2BpH263VZOm8QnVD9YQsCHk= Content-Type: text/plain; charset="utf-8" Content-ID: <462D36FA73043044B6D2E282DD30856E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c6aa697b-40d2-476d-ce85-08d6a6c5b999 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 08:35:47.0365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2233 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42KZGbG9RDclvz3G4PMVU4vZf7cwWszsmM7i wOSxZMlPpgDGKC6blNSczLLUIn27BK6MTefvMxbsE6pYsfkJcwNjg1AXIyeHhICJRHPzB5Yu Ri4OIYEjjBLtb5ZDOd8YJW5cfcQG57xfOocJwlnCJLH45X1GEIdFYAKzxN3L3xghMlOYJPoW XGaFcJ4DTXt9mglkDZuAjcSFh+9ZQWwRAWWJqVMOAw3m4GAWMJT4uacQJCwsoCTxe9INZogS dYkJR/6zQdh6Eifm7WIBsVkEVCUuXVnODNLKK2Av8fG/HkiYUUBW4kvjarBWZgFxiVtP5jNB PCcgsWTPeWYIW1Ti5eN/rBC2gsSr7gY2CFtW4tL8bkYI21fi/8mlYC9LCNxmlPj0pxVqkI7E wXk7oYqkJE5cPAo1KF9iatsFdghbRuL0vp1QzX9ZJZ6c/QnWLCSQKrF8bSsjxKXJEldu90E1 yEms6n3IMoFRdxaSw2eBg0VTYv0ufQjTQ2JlXyREhaLElO6H7CA2r4CgxMmZT1gWMLKuYhQt Ti1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAhMIge3/DbYwfjyueMhRgEORiUe3keO7TFCrIllxZW5 hxglOJiVRHgtcoBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef8ICcYICaQnlqRmp6YWpBbBZJk4 OKUaGAM0Nvu/2vi4MPbCj1XOPEqftB7V5EpNvLC/SjMgh7GnMMbkq0r8pB6xn4vNHF8tXXAg pPLW/X+JCTr1/CzrLff0TWr40W7NcHDFzw0qYtWph1WEeOTjuDcKzN275aJpWfGtd8u65up+ LH3mvVIo+/CVzyx/turXv0xeMtU3JP1KXbrQEV9+FiWW4oxEQy3mouJEALcr+4AeAwAA Archived-At: Subject: [Cbor] Slot request for IETF 104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 08:35:54 -0000 SGkgYWxsLA0KDQpJZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIGEgcHJlc2VudGF0aW9uIHNsb3Qg ZHVyaW5nIG91ciBtZWV0aW5nIGluIFByYWd1ZSwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cu DQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQrvu79PbiAwMS8wMy8yMDE5LCAyMjoxMCwgIiJJRVRG IFNlY3JldGFyaWF0IiIgPGFnZW5kYUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBEZWFyIEZyYW5j ZXNjYSBQYWxvbWJpbmksDQogICAgDQogICAgVGhlIHNlc3Npb24ocykgdGhhdCB5b3UgaGF2ZSBy ZXF1ZXN0ZWQgaGF2ZSBiZWVuIHNjaGVkdWxlZC4NCiAgICBCZWxvdyBpcyB0aGUgc2NoZWR1bGVk IHNlc3Npb24gaW5mb3JtYXRpb24gZm9sbG93ZWQgYnkNCiAgICB0aGUgb3JpZ2luYWwgcmVxdWVz dC4gDQogICAgDQogICAgDQogICAgICAgIGNib3IgU2Vzc2lvbiAxICgyOjAwIHJlcXVlc3RlZCkN CiAgICAgICAgVGh1cnNkYXksIDI4IE1hcmNoIDIwMTksIE1vcm5pbmcgU2Vzc2lvbiBJIDA5MDAt MTAzMA0KICAgICAgICBSb29tIE5hbWU6IEthcmxpbiAzIHNpemU6IDYwDQogICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIA0KICAg IGlDYWxlbmRhcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNC9zZXNz aW9ucy9jYm9yLmljcw0KICAgIA0KICAgIFJlcXVlc3QgSW5mb3JtYXRpb246DQogICAgDQogICAg DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgV29ya2luZyBHcm91cCBOYW1lOiBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVw cmVzZW50YXRpb24gTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMNCiAgICBBcmVhIE5hbWU6IEFw cGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWENCiAgICBTZXNzaW9uIFJlcXVlc3RlcjogRnJh bmNlc2NhIFBhbG9tYmluaQ0KICAgIA0KICAgIE51bWJlciBvZiBTZXNzaW9uczogMQ0KICAgIExl bmd0aCBvZiBTZXNzaW9uKHMpOiAgMiBIb3Vycw0KICAgIE51bWJlciBvZiBBdHRlbmRlZXM6IDUw DQogICAgQ29uZmxpY3RzIHRvIEF2b2lkOiANCiAgICAgRmlyc3QgUHJpb3JpdHk6IGFydGFyZWEg ZGlzcGF0Y2ggc2VjZGlzcGF0Y2ggc2FhZyBleHRyYSBqbWFwIHV0YSBkbWFyYyBpYXNhMiBjb3Jl IGFjZSB0MnRyZyBjb3NlDQogICAgIFNlY29uZCBQcmlvcml0eTogc3VpdCBsd2lnIGFuaW1hIDZ0 aXNjaA0KICAgICBUaGlyZCBQcmlvcml0eTogYWNtZSByb2xsIGRldG5ldCBzYWNtIGxwd2FuIGRv dHMNCiAgICANCiAgICANCiAgICBQZW9wbGUgd2hvIG11c3QgYmUgcHJlc2VudDoNCiAgICAgIENh cnN0ZW4gQm9ybWFubg0KICAgICAgQmFycnkgTGVpYmENCiAgICAgIEFsZXhleSBNZWxuaWtvdg0K ICAgICAgRnJhbmNlc2NhIFBhbG9tYmluaQ0KICAgIA0KICAgIFJlc291cmNlcyBSZXF1ZXN0ZWQ6 DQogICAgDQogICAgU3BlY2lhbCBSZXF1ZXN0czoNCiAgICAgIFBsZWFzZSBhdm9pZCBjb25mbGlj dCB3aXRoIEFSVCBhbmQgSW9ULXJlbGF0ZWQgQm9Gcw0KICAgIA0KICAgIFBsZWFzZSBhdm9pZCBG cmlkYXk6IG9uZSBjaGFpciBoYXMgdG8gbGVhdmUgb24gZWFybHkgRnJpZGF5IG1vcm5pbmcNCiAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICANCiAgICANCg0K From nobody Wed Mar 13 06:50:28 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2266129284 for ; Wed, 13 Mar 2019 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 eZ48tH9XwVaU for ; Wed, 13 Mar 2019 06:50:24 -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 349C21240D3 for ; Wed, 13 Mar 2019 06:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2DDoFeG018172 for ; Wed, 13 Mar 2019 14:50:20 +0100 (CET) Received: from client-0134.vpn.uni-bremen.de (client-0134.vpn.uni-bremen.de [134.102.107.134]) (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 44KCs332b2z1Bp8; Wed, 13 Mar 2019 14:50:15 +0100 (CET) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_7B5CC273-2273-4917-96BF-9F44B7A12BCD" X-Mao-Original-Outgoing-Id: 574177811.714317-b2c7b631d380081746514daaf0bc584b Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 13 Mar 2019 14:50:14 +0100 Message-Id: <599B84C7-3581-4339-BB5F-C02D5FDD1BDB@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Cbor] Fwd: [cbor-wg/CBORbis] Try for two levels of decoding error? (#45) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:50:27 -0000 --Apple-Mail=_7B5CC273-2273-4917-96BF-9F44B7A12BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With much of Jeffrey=E2=80=99s #17 accepted (in slightly edited form as = #61), I think we can revisit #45. Here is my most recent comment on the issue. Are the three levels the right ones? Have we nailed strict mode? Fresh editor=E2=80=99s copy at = https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html = (all variants via https://cbor-wg.github.io/CBORbis/ = ). Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: cabo > > Subject: Re: [cbor-wg/CBORbis] Try for two levels of decoding error? = (#45) > Date: March 13, 2019 at 14:44:39 GMT+1 > To: cbor-wg/CBORbis > > Cc: Subscribed > > Reply-To: cbor-wg/CBORbis = > >=20 > Essentially, we now have three levels: >=20 > well-formed (vs. syntactic error). Not well-formed is now MUST NOT = generate/accept. > valid (vs. semantic error). Protocol encoders now MUST generate valid = CBOR. > expected (vs. unexpected by application). This is application-specific = and often expressed in CDDL. > I'm not sure we have all in order for strict mode, so I'll leave this = open for now, but I think we have nailed the levels. >=20 > =E2=80=94 > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub = , = or mute the thread = . >=20 --Apple-Mail=_7B5CC273-2273-4917-96BF-9F44B7A12BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 With = much of Jeffrey=E2=80=99s #17 accepted (in slightly edited form as #61), = I think we can revisit #45.

Here is my most recent comment on the issue.

Are the three levels the = right ones?
Have we nailed strict mode?

Fresh editor=E2=80=99s = copy at https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html<= /a>
(all variants via https://cbor-wg.github.io/CBORbis/ ).

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


Begin = forwarded message:

From: = cabo <notifications@github.com>
Subject: = Re: = [cbor-wg/CBORbis] Try for two levels of decoding error? (#45)
Date: = March 13, 2019 at 14:44:39 = GMT+1
To: = cbor-wg/CBORbis <CBORbis@noreply.github.com>
Cc: = Subscribed <subscribed@noreply.github.com>
Reply-To: = cbor-wg/CBORbis <reply+00f4be62a8c49a99fc36ffb59deedd89656aa5d99e3b2c0e92cf00000= 00118a0cb4792a169ce17908f7d@reply.github.com>

Essentially, we now have three levels:

  • well-formed (vs. syntactic error). Not well-formed is = now MUST NOT generate/accept.
  • valid (vs. semantic error). Protocol encoders now MUST = generate valid CBOR.
  • expected (vs. unexpected by application). This is = application-specific and often expressed in CDDL.

I'm not sure we have all in order for strict mode, so = I'll leave this open for now, but I think we have nailed the = levels.

=E2=80=94
You are receiving this because you = are subscribed to this thread.
Reply to this email = directly, view it on GitHub, or mute the = thread.3D""


= --Apple-Mail=_7B5CC273-2273-4917-96BF-9F44B7A12BCD-- From nobody Wed Mar 13 09:49:52 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6181310B7 for ; Wed, 13 Mar 2019 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=VNbHzvsU; dkim=pass (1024-bit key) header.d=ericsson.com header.b=nCRvnQg5 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 EE8tl2tA2p1i for ; Wed, 13 Mar 2019 09:49:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9649C1310A0 for ; Wed, 13 Mar 2019 09:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552495774; x=1555087774; 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=6hErp4gwiEpo9ynB7aOjJz0kkiYqyQOB/WYqfKsvgmM=; b=VNbHzvsUAHcH787Jx8sfnHzDaB7rvzGNitPKlQByanhnbp6M4xOKHLFY6lFO7icK /mOgtFFL7eaC0cYjjluIvZHu0dy45OygwJYjYl8QZElUSr+JNoLKYjcDO2PoxA/w eVU7UuHNM4f7Vcl4BG6/FtzFSrDBvFkWD32DySfNpeQ=; X-AuditID: c1b4fb25-da1ff70000005ff7-95-5c89349e97db Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 66.71.24567.E94398C5; Wed, 13 Mar 2019 17:49:34 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) 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; Wed, 13 Mar 2019 17:49:34 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 13 Mar 2019 17:49:34 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) 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; Wed, 13 Mar 2019 17:49:33 +0100 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=6hErp4gwiEpo9ynB7aOjJz0kkiYqyQOB/WYqfKsvgmM=; b=nCRvnQg5bZRz8T9jGKJefROQ79Es6/AxowrB+58qSQ8MxvkHCNU0Lz1Rw2oO7SxoLiIUwfWE2rIeY+NshqxeUGECZmC5fuxq+WfoRWUYMRCToORwpXUCgNv1Qeygo8bRRYLBl+SUAHQAFnD/d4kAubIncO2krOi49V0wij9NDEs= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3178.eurprd07.prod.outlook.com (10.170.245.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.5; Wed, 13 Mar 2019 16:49:33 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1709.011; Wed, 13 Mar 2019 16:49:33 +0000 From: John Mattsson To: "cbor@ietf.org" Thread-Topic: [Cbor] correctness of implied top level array? Thread-Index: AQHU2by7czABdriimU2Tsqkq++U7DA== Date: Wed, 13 Mar 2019 16:49:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7fcefe1b-81c8-4376-e009-08d6a7d3de65 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3178; x-ms-traffictypediagnostic: HE1PR07MB3178: x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(39860400002)(376002)(366004)(189003)(199004)(5660300002)(2906002)(6436002)(68736007)(2501003)(102836004)(6916009)(3846002)(6116002)(66066001)(2351001)(83716004)(36756003)(486006)(229853002)(4744005)(186003)(2616005)(6506007)(476003)(71200400001)(26005)(6486002)(71190400001)(6512007)(25786009)(478600001)(86362001)(99286004)(53936002)(5640700003)(82746002)(305945005)(256004)(316002)(7736002)(6246003)(58126008)(14454004)(44832011)(1730700003)(81166006)(81156014)(33656002)(8676002)(105586002)(106356001)(97736004)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3178; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 59xQ+fYDK34lfU17LMboQEkh0fbNzIRnRAPSJHJdBCPwy+q7YJrpHkaR4F+irCDtt8lvFJ53b+11DPYVi6PyoFwLf9/6tpDgTTn1JUqYFLJIv9b6q0zlvoC6sQ0GMniKyOHKAxTG8I3fEnl+gtO6hoiAhpGs/tSS0Lq6ZjVExrDVoEqdzEGPD0KpVFB+yHEKHzFTbqcd1ncFHD4au42+NIFFEbxk2t4xZtjyzxg27v9xpIZhMt/ZcMzL7cafCInPrnQC7KEBCc/K4zZmkF2twOt2BWu2+loe/h+odriEjwvTb5ulEk4ZvXw+7suV1rUISSaJ1pp2Xd2+sg+qNPxN307zygWwkpx+ySLYFgy40Xk4V9BjLZ942R7ySaHrDtUEDI2muM2z0vxKfViwbL5Ihs6UyyWApuQVX4ZgFtJq+H4= Content-Type: text/plain; charset="utf-8" Content-ID: <9FC1124F5D33EB4582E8101134BFD51E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7fcefe1b-81c8-4376-e009-08d6a7d3de65 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 16:49:32.6247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3178 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbG9THeeSWeMwffvKhYzO6azODB6LFny kymAMYrLJiU1J7MstUjfLoEro7nrM2vBJNaKtTOusjQwNrB2MXJySAiYSPS+/8PcxcjFISRw hFHizPSNjBDON0aJbQfeMMM5809cYIdwljBJ3Fv0GCzDIjCBWeL0olusEJlJTBKr7m9jg3Ae AE2bfYMRZA2bgIHE3D0NbCC2iICyxNQph8FsYQFriRsHpzJDxG0klj3+AVWjJ7FhdhMTiM0i oCox5cZjsBpeAXuJG3vb2UFsRgExie+n1oDVMAuIS9x6Mp8J4iUBiSV7zjND2KISLx//A3tV VEBfYkvfAxaI3liJ1tbpQHEOoBoFiYdb/SDKZSUuze9mhLB9Je4t2w32i4TATUaJd1v2skDU a0n03amDMLMlHq9VhiiXkbi6oJsJovweq8ST9dPBzhQSSJVYvrYVaqacxKrehywQReeZJfbM 3cs4gVFnFpIXZgHNZRbQlFi/Sx8i7CFxfNkrZghbUWJK90P2WeCQEJQ4OfMJywJG1lWMosWp xUm56UbGeqlFmcnFxfl5enmpJZsYgcnj4JbfqjsYL79xPMQowMGoxMN7V7kzRog1say4MvcQ owQHs5IIb6geUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvHyHBGCGB9MSS1OzU1ILUIpgsEwen VAMjq0Xok0ajq4usAm9o9Uimv/93KGv+l/5dMxZy+M8PdXy+QVNL+r2wY9fiBWfY0z8kLbq4 9Na8V3Vuzb8KVwZfm7g1y1jpPaPi7n2+VlM+u6bmexV+6zRY73r/c9UmnydFyeUa6yUSXv+a JLAk6+Nc5TVNRvGyukf6X3SpsQiHFb4SDkxO685WYinOSDTUYi4qTgQA468a4RoDAAA= Archived-At: Subject: Re: [Cbor] correctness of implied top level array? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:49:50 -0000 IEhpLA0KDQpHcmVhdCB3aXRoIGEgZG9jdW1lbnQgdGhhdCBkZWZpbmUgYSBDQk9SIHNlcXVlbmNl LiBJIGhhdmUgYWxyZWFkeSBtYWRlIGRyYWZ0LWJvcm1hbm4tY2Jvci1zZXF1ZW5jZSBhIG5vcm1h dGl2ZSByZWZlcmVuY2UgaW4gRURIT0MuDQoNCkkgd291bGQgbGlrZSB0byBzZWUgQ0RETCBhbmQg Q0JPUiBkaWFnbm9zdGljIG5vdGF0aW9uIGZvciBhIENCT1Igc2VxdWVuY2UuIEluIGxhY2sgb2Yg c29tZXRoaW5nIGJldHRlciwgRURIT0MgaXMgY3VycmVudGx5IHVzaW5nIHRoZSBDRERMIGdyb3Vw IG5vdGF0aW9uOg0KDQptZXNzYWdlXzEgPSAoDQogIFRZUEUgOiBpbnQsDQogIFNVSVRFU19VIDog c3VpdGUgLyBbIGluZGV4OiB1aW50LCAyKiBzdWl0ZSBdLA0KICBYX1UgOiBic3RyLA0KICBDX1Ug OiBic3RyLA0KICBJRF9QU0sgOiBic3RyIC8gaGVhZGVyX21hcCwNCiAgPyBVQURfMSA6IGJzdHIs DQopDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Wed Mar 13 09:56:37 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E422130FB4 for ; Wed, 13 Mar 2019 09:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[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 QBcYuYafWUh4 for ; Wed, 13 Mar 2019 09:56: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 14A90130F35 for ; Wed, 13 Mar 2019 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2DGuLFF016516; Wed, 13 Mar 2019 17:56:26 +0100 (CET) Received: from client-0134.vpn.uni-bremen.de (client-0134.vpn.uni-bremen.de [134.102.107.134]) (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 44KHzn1RW6z1Bp8; Wed, 13 Mar 2019 17:56:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 13 Mar 2019 17:56:20 +0100 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 574188978.916838-0bc13306cc8c4df3610674f859baeea8 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Mattsson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] correctness of implied top level array? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:56:35 -0000 On Mar 13, 2019, at 17:49, John Mattsson = wrote: >=20 > Hi, >=20 > Great with a document that define a CBOR sequence. I have already made = draft-bormann-cbor-sequence a normative reference in EDHOC. >=20 > I would like to see CDDL and CBOR diagnostic notation for a CBOR = sequence. In lack of something better, EDHOC is currently using the CDDL = group notation: >=20 > message_1 =3D ( > TYPE : int, > SUITES_U : suite / [ index: uint, 2* suite ], > X_U : bstr, > C_U : bstr, > ID_PSK : bstr / header_map, > ? UAD_1 : bstr, > ) That is probably where we want to go, but not with CDDL version 1. For now, both diagnostic notation and CDDL can use an array and just say = in English that we are not using a single data item but a CBOR sequence = instead. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 13 10:11:10 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEBF130F50 for ; Wed, 13 Mar 2019 10:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=UBMVEMAX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=SbzFnBr/ 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 rOWLaLs9DiZe for ; Wed, 13 Mar 2019 10:11:06 -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 0B4D3131064 for ; Wed, 13 Mar 2019 10:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552497046; x=1555089046; 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=1scAM3/J+n2/AB0NW69GLPhm0U5bXr+PJJOpEiC7Cvs=; b=UBMVEMAX38iHLz+U5S+m6Lt4mdu8CGjdi7AnX/iGZJJSNPikguO14uJmF8c1I/2B 2FUkSWPOIDyUNcS0E7eYumSR7YDmMeEBbzRzkm10LbccaFnDQxzzGqiJU8yjoY80 qBtDG2hRE+MlL0DzOalh58VEZ89odOgeuZqsE8e09GA=; X-AuditID: c1b4fb3a-5c9c29e00000672c-81-5c8939967be7 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.32.26412.699398C5; Wed, 13 Mar 2019 18:10:46 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 13 Mar 2019 18:10:39 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) 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; Wed, 13 Mar 2019 18:10:39 +0100 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=1scAM3/J+n2/AB0NW69GLPhm0U5bXr+PJJOpEiC7Cvs=; b=SbzFnBr/p4HaWMhcjDvwCWzNo7VbBsMNoe+48qrJi64jUoxs0sTPsuq+xF1EGQtWuaGO/QXliFbnNQNMMRgYpEGs0FnoPRTMjUtGOTTk+JZQIsOLAozIFgpnwq7TNwH5dZOz1LqG7ZvFMFPV23pfC0S9lQhJVDgpZKb5rujNmtc= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2140.eurprd07.prod.outlook.com (10.168.35.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Wed, 13 Mar 2019 17:10:38 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58%10]) with mapi id 15.20.1730.003; Wed, 13 Mar 2019 17:10:38 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: Reminder: CBOR Virtual Meeting: 2019-03-13 Thread-Index: AQHU2b+tYopZgWHpYUWLdnoO4kG5vw== Date: Wed, 13 Mar 2019 17:10:37 +0000 Message-ID: <9F2D556B-03A8-4D42-8A16-6EFB9DA4CC24@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f44ded43-251d-499d-e1d3-08d6a7d6d07f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2140; x-ms-traffictypediagnostic: HE1PR0701MB2140: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(366004)(39860400002)(189003)(199004)(12213003)(497574002)(82746002)(68736007)(6512007)(5660300002)(53936002)(6306002)(86362001)(966005)(105586002)(66574012)(7736002)(316002)(186003)(2501003)(26005)(6486002)(14444005)(256004)(36756003)(3846002)(6116002)(8936002)(25786009)(5640700003)(6436002)(102836004)(97736004)(14454004)(6506007)(478600001)(16799955002)(305945005)(486006)(2351001)(8676002)(81156014)(81166006)(66066001)(71200400001)(1730700003)(83716004)(33656002)(99286004)(44832011)(2906002)(476003)(106356001)(2616005)(71190400001)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2140; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YPeeyiJKfrOi7oj0WrRP9GadSe0Z055byNs/x8qxkZQzXNAEWuEeZYnRiwb5LHdAV0qJoryWcM6D5FLgCP8hh5oswBJiED1NSEPslJvU31e35iCJyAk1M1UY9TQzc/gM0U6CiaA8Z5funyYSRGz+m1I2ci5/sNcoXJ5RHtjG2D2Qc5uedj19HbsR6v2QiLCxkG9TVRqAdgKTEoveKHU+jblJLIa4YK6hSyyeiDrv4xtrq9/vcNXc0/ozGFiTd++6bzDdwF1uIQYK15Ee6Nv1u3a37QjUivGCVH0iA4TA4ffunKJTbK4tI+ngs/khLHqWT+S69bmh357rvDN8kdPdVu/Ce7BKBx88QtZHfb1O3oRHWMAFEwKdk1ASDiFDHS8pGT2pHF5gGxgJyonDYkxeR0Qfsbk9+KNcMBu/ZuCElXI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f44ded43-251d-499d-e1d3-08d6a7d6d07f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 17:10:38.0333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2140 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZGbG9WHeaZWeMweqbnBYzO6azODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/4Vp4JP/BX33x5la2Dcw9/FyMEhIWAi8WGeQhcjJ4eQwBFG ib6rpl2MXED2N0aJ2ZMeM0M4S5gktretYQJxWAQmMEs0r9jJBJGZxiSx8ucpNgjnOaPE/xtz 2ECGsQnYSFx4+J4VxBYRUJaYOuUwWFxYwFji4aUeNoi4hcSbdYdYQe4QEdCTuHwnCCTMIqAq 0ff/BROIzStgL3HgwWdGEJtRQFbiS+NqZhCbWUBc4taT+WA1EgICEkv2nGeGsEUlXj7+xwph K0u8v3CaEcKWlbg0vxvK9pW4uucc2M0SArcZJWasvQXVoCMxf95GKFtK4vvjj+wQi5Mlrtzu Y4eI50tMvfeEBcKWkbi6oJsJYlATm8TfZQeYISGZKrF8bSvUNjmJVb0PWSCKzjNLLJj8Eexj ZgFNifW79Ccwas9C8tAshAxE2EPi8pxbzBC2osSU7ofss8DhIihxcuYTlgWMrKsYRYtTi4tz 042M9FKLMpOLi/Pz9PJSSzYxAtPGwS2/rXYwHnzueIhRgINRiYc3SLkzRog1say4MvcQowQH s5IIb6geUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvHyHBGCGB9MSS1OzU1ILUIpgsEwenVAMj l8OrTW9CJ1uEZSydErR94/TK3WZmBz/+qH2rukGt8mHier1I3cwFjK8SZ0/82DWlNuCWUejU 4M4lB+Ky1vnyfnViaFyVWZctyasTNjf9irzjxOVLNkZtuv+r/ufiirrPRcYifadL5Jf8arBb GCB5lGfvw09XoqcHThSbZfA+cGlbXMWzeTYTlFiKMxINtZiLihMBIQKAPBcDAAA= Archived-At: Subject: [Cbor] Reminder: CBOR Virtual Meeting: 2019-03-13 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 17:11:09 -0000 UmVtaW5kZXI6IFRoZSBuZXh0IENCT1IgdGVsZWNvbmZlcmVuY2UgaXMgaW4gNTAgbWludXRlcy4N Cg0KV2ViZXg6DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjMxYjhl NjNjZmQzNTRjYTg0NjFiOTk4YWEzMGM0YmEgDQoNClRhbGsgdG8geW91IHNvb24sDQpGcmFuY2Vz Y2ENCg0K77u/T24gMDMvMTIvMjAxOCwgMTg6MzEsICJDQk9SIG9uIGJlaGFsZiBvZiBJRVNHIFNl Y3JldGFyeSIgPGNib3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWVzZy1zZWNyZXRh cnlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXBy ZXNlbnRhdGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoY2JvcikgV29ya2luZyBHcm91 cCB3aWxsIGhvbGQNCiAgICBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDIwMTktMDMtMTMg ZnJvbSAxODowMCB0byAxOTowMCBVVEMuDQogICAgDQogICAgVGhlIENCT1Igd29ya2luZyBncm91 cCB3aWxsIGhhdmUgY29uZmVyZW5jZSBjYWxscyBydW5uaW5nIGV2ZXJ5IHR3byB3ZWVrcyB0aHJv dWdoIHRoZSBlbmQgb2YgTWFyY2ggKHVudGlsIElFVEYgMTA0IGluIFByYWd1ZSkuICAgDQogICAg RGF5OiBldmVyeSBvdGhlciBXZWRuZXNkYXkgYmVnaW5uaW5nIG9uIDE5IERlY2VtYmVyIA0KICAg IERhdGVzOiAxOSBEZWM7IDIsIDE2LCAzMCBKYW47IDEzLCAyNyBGZWI7IDEzIE1hcmNoIA0KICAg IFRpbWU6IDE4OjAwIHRvIDE5OjAwIFVUDQogICAgDQogICAgQWdlbmRhOg0KICAgIChObyBhZ2Vu ZGEgc3VibWl0dGVkKQ0KICAgIA0KICAgIEluZm9ybWF0aW9uIGFib3V0IHJlbW90ZSBwYXJ0aWNp cGF0aW9uOg0KICAgIFdlIHdpbGwgdXNlIHRoZSB3b3JraW5nIGdyb3VwIFdlYkV4IGZvciB0aGUg Y2FsbHMuICBUaGUgSUVURiBXZWJFeCBhY2NvdW50IGRvZXMgbm90IGFsbG93IEludGVybmF0aW9u YWwgZGlhbGluZyBub3IgVVMgdG9sbCBmcmVlICgiODAwIiBudW1iZXJzKSwgYnV0IHlvdSBjYW4g dXNlIHRoZSBXZWJFeCBhcHAgdG8gY29ubmVjdCB5b3VyIGRldmljZSBhdWRpbywgYW5kIHRoZXJl J3MgYWxzbyB0aGUgb3B0aW9uIG9mIGNvbm5lY3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dz ZXIgaWYgeW91ciBicm93c2VyIHN1cHBvcnRzIGl0LiAgV2ViRXggZGV0YWlscyB3aWxsIGJlIHNl bnQgdG8gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgZWFjaCBjYWxsICh0aGUgZGV0YWlscyB3aWxs IGJlIHRoZSBzYW1lIGZvciBhbGwgY2FsbHMsIGJ1dCB0aGUgbWVzc2FnZXMgd2lsbCBzZXJ2ZSBh cyByZW1pbmRlcnMpLg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3Jn DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgDQoN Cg== From nobody Wed Mar 13 11:29:37 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F9130F35 for ; Wed, 13 Mar 2019 11:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.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 iTKFk7bi3VF6 for ; Wed, 13 Mar 2019 11:29:31 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 86C0612AF7E for ; Wed, 13 Mar 2019 11:29:31 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x13so2498025ljj.5 for ; Wed, 13 Mar 2019 11:29:31 -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=w04qyRO2ycN5yF0JktKxZ9lZqmGWnbtCxS1+29Vgdi4=; b=aDOkQZDdB7tKf32cVRa1L2pPZduqwYT8MJZpCok4mazDNB33ne5hT5H1XHVWzxhtKW F27mHstIZkGDzGtSdUSGfDJIg4C2cDOGgZJQHzalvjIGJp9GqBSytmKaV+uYOKTTRDOw ADbqool1Dqh1J3dfABrt4bcydLoWv9h2aNBRY= 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=w04qyRO2ycN5yF0JktKxZ9lZqmGWnbtCxS1+29Vgdi4=; b=guAefoURTNyaQiAQVKsHedMHomQ4pH8pL4WsXEqojyQb8CXRrac2jDenvDJkPqw2pk 4KsCrneVo9hZXOK3Z8vNwEFTTgpHUNEAYg7ciqEoVExWu1teXBsmqz5GWcopq+7HGFh2 RUY3chG4UaQVVL81kbKdVQZ/fwZAhVlSeC31+e18DtsXW6Urn00wAiBE4ViPyp4NKVYy 4ekVi5yowcRUyIjK6WtTv9T5eyiZjfGcclfI7zgfAdkE997gephn4/YQe/0OKMN6EAdy /Q0LobWjrYFMt+ue9I/Uiwjrdv4MlUXL5+zJ0v0frJFuJNZbQfSopBOZ1x6OoEIqqZCp NCKw== X-Gm-Message-State: APjAAAVx4CUNuuV5DXKrG4uHs6VrL975yMa4sq/YCU7yDIz3tfNGq7u/ Fz97HGyr3st1dYmQkVQ1+bRk4nVYnDr/kooxXQr1HA== X-Google-Smtp-Source: APXvYqydWvQzj6NB+kgkEgZtk1h4a65rdxrYlTU0B0tWeegL9cQXgj3f1dQ68vDuAydHWldZ/f27/q4lNIhoUPlr/Mw= X-Received: by 2002:a2e:811:: with SMTP id 17mr25403085lji.42.1552501769435; Wed, 13 Mar 2019 11:29:29 -0700 (PDT) MIME-Version: 1.0 References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> In-Reply-To: <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> From: Jeffrey Yasskin Date: Wed, 13 Mar 2019 11:29:17 -0700 Message-ID: To: Laurence Lundblade Cc: Francesca Palombini , "cbor@ietf.org" , "draft-ietf-cbor-array-tags@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007b64910583fdfcda" Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:29:34 -0000 --0000000000007b64910583fdfcda Content-Type: text/plain; charset="UTF-8" On Fri, Mar 8, 2019 at 7:43 AM Laurence Lundblade wrote: > In addition to what I said before, a deterministic encoding should be > specified (formerly known as canonical) in the specification and that > should probably be network / big endian. > I think it's the job of the protocol to describe how it's encoded deterministically, rather than this tag. For example, the choice of whether or not to tag an array at all is a potential point for non-determinism to enter, so the protocol needs to specify whether there's a tag, and if so, which one. At that point, it's made the choice of little-vs-big endian, so there's no more question for this document to answer. Jeffrey --0000000000007b64910583fdfcda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 8, 2019 at 7:43 AM Laurence L= undblade <lgl@island-resort.com= > wrote:
In addition to what I said before, a determinist= ic encoding should be specified (formerly known as canonical) in the specif= ication and that should probably be network / big endian.
<= div>
I think it's the job of the protocol to describe how= it's encoded deterministically, rather than this tag. For example, the= choice of whether or not to tag an array at all is a potential point for n= on-determinism to enter, so the protocol needs to specify whether there'= ;s a tag, and if so, which one. At that point, it's made the choice of = little-vs-big endian, so there's no more question for this document to = answer.

Jeffrey
--0000000000007b64910583fdfcda-- From nobody Wed Mar 13 11:53:52 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00C9130EF7 for ; Wed, 13 Mar 2019 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ahJVXM3p; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kOE+VWIE 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 MK0txPto6nRI for ; Wed, 13 Mar 2019 11:53:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 57A1E12AF7E for ; Wed, 13 Mar 2019 11:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552503225; x=1555095225; 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=oS5tNV9orjFHWhmZDRRNmL0PBP0qyL6EJm++UTaUPqg=; b=ahJVXM3pqoTUhnHvVtZSaTg9urwxs2p5r79hWEESWUJ9Ujkbzjm+qrtX9iKg5G2V p4aM6KdQgvgYEJE6DANJ03GNCIkoLjjHhrd6F5gPWinyoFziKGoty+O9oIzSX+1d vCma2g4zIrEEIy58+WabikLxza1Qo3jAhyTwQJf1mKU=; X-AuditID: c1b4fb30-f93ff7000000355c-d4-5c8951b9c06e Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.71.13660.9B1598C5; Wed, 13 Mar 2019 19:53:45 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) 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; Wed, 13 Mar 2019 19:53:44 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) 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; Wed, 13 Mar 2019 19:53:44 +0100 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=oS5tNV9orjFHWhmZDRRNmL0PBP0qyL6EJm++UTaUPqg=; b=kOE+VWIEnQqVedovrWMnJb/JDf+xU5TymuxDp7ZojHCMQUw++vokw1PG1mST10X96nsTWCyUMfjSbQxPvbEC2a4wdX9OH2CU8bfAu9l4/QI+24jIYrJu0c2jrSN5pOQpp0KHFwTlx3E1bLEbPpXW/vaAcV77H+rQ6TfajaOC3ZI= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2793.eurprd07.prod.outlook.com (10.168.188.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.4; Wed, 13 Mar 2019 18:53:43 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::f83b:7f0f:a7df:3c58%10]) with mapi id 15.20.1730.003; Wed, 13 Mar 2019 18:53:43 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: [Cbor] Reminder: CBOR Virtual Meeting: 2019-03-13 Thread-Index: AQHU2c4Utd/LrY8EeEaKBfcP+rQezQ== Date: Wed, 13 Mar 2019 18:53:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.192.159.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2531de10-9932-421a-d7ac-08d6a7e53746 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2793; x-ms-traffictypediagnostic: HE1PR0701MB2793: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(366004)(136003)(189003)(199004)(12213003)(497574002)(53754006)(5640700003)(6916009)(6486002)(8676002)(229853002)(6436002)(99286004)(66574012)(2906002)(1730700003)(68736007)(36756003)(105586002)(6246003)(2501003)(81156014)(6346003)(66066001)(2351001)(106356001)(256004)(6116002)(14444005)(3846002)(33656002)(81166006)(26005)(25786009)(71200400001)(97736004)(478600001)(2616005)(71190400001)(305945005)(83716004)(16799955002)(82746002)(44832011)(6306002)(102836004)(316002)(186003)(53936002)(6512007)(5660300002)(486006)(8936002)(86362001)(476003)(14454004)(966005)(6506007)(53546011)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2793; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gn275cpDMv4ze/h3ikkDSBQK8Sug6sbAtJocOz9Kn0WOgk6cLRBzamkdBdntoNPJJrJ3sVCgx3zWC882I/YOUg2VQLvOkAp1RZEi81Cfy5ux5H9Ds9CoLqT/bqi/0L3RlN3Y0R/utcE63jAjcDS/DOChvx8SfFejQd3BhkCkIr3TIaSlayNyb0Iv1rInycX1oQqKUkuMWp84AYtfL91QQJcSR2Ea3lcj0dJMAl50d7gyZ8xTfYTVsic3arBtGr7aTB+lUDs1xERsBVsOXoe2MdXNQcECgCiPn4ZBa36/TEcY4ULG/5X3JW79cBd8tQfaj033QzFYw9EYBu2E+/46f70g147lP5X39pclA91ZFH+sgmTRtHOpIcPqKnUb5ryXLlCh3aDr/WnO4DoTzYpMMGD3Wj/pN+UzsyGgTab38Gg= Content-Type: text/plain; charset="utf-8" Content-ID: <770A04768F90A5489A8DC66328A85F32@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2531de10-9932-421a-d7ac-08d6a7e53746 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 18:53:43.5011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2793 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbG9XHdnYGeMwfnnPBYzO6azODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Wty2wFzzQqdt89xNTA+EC9i5GTQ0LARKL95y0mEFtI4Aij xJ+l0V2MXED2N0aJNc/PM0E4S5gkrq9tYwZxWAQmMEssPdDIApGZziSx+P9PNgjnOaNEx9n9 zCDD2ARsJC48fM8KYosIKEtMnXIYqIidQ1jATqKrACJqL7HmxTJmCFtP4sbTt2BnsAioSmy8 0M4IYvMC1Tx90MYGYjMKyEp8aVwNVs8sIC5x68l8JogXBCSW7DnPDGGLSrx8/I8VwlaSeHLq EZQtK3FpfjcjhO0rMfnrd0aQkyUEbjNKLJpxG6pZR2Lx6z9QRVIS3x9/ZIew8yW+nF/AAmHL SFxd0M0E0byZTWLto5uMkMBLlVi+tpUR4tJkiSu3+6Ca5SRW9T5kgWg4zyzxZf5loAQH0Aua Eut36U9g1J6F5KFZCBmIsIfEpUnX2SBsRYkp3Q/ZZ4HDRVDi5MwnLAsYWVcxihanFiflphsZ 6aUWZSYXF+fn6eWllmxiBCaOg1t+G+xgfPnc8RCjAAejEg/vA/vOGCHWxLLiytxDjBIczEoi vKF6QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8f4QEY4QE0hNLUrNTUwtSi2CyTBycUg2M81Oa V73dYGhQmz6j1UrjrOP++Ude/ynbLmmo+lSOZbnVof87hSytf2Ymr5u2Ss1upfiaCMPXAhtX 1eieeOI+o31f8B6z1FprY8vgY1uXXoqOk897sN/rUXEE30uFUiGJ8oz9l0qtDY67T9vU/CfD vbd/e4TSgQale/t7emN2czn5xO7VlgtTYinOSDTUYi4qTgQAGEQmoRgDAAA= Archived-At: Subject: Re: [Cbor] Reminder: CBOR Virtual Meeting: 2019-03-13 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:53:51 -0000 SGkgYWxsLA0KDQpIZXJlIGFyZSB0aGUgbWludXRlcyBmcm9tIHRvZGF5J3MgaW50ZXJpbSwgYWxz byB1cGxvYWRlZCB0byB0aGUgZGF0YXRyYWNrZXIuIEZvciB0aGUgcHJlc2VudHMsIHBsZWFzZSBs ZXQgbWUga25vdyBpZiBhbnl0aGluZyB3YXMgaW5jb3JyZWN0bHkgY2FwdHVyZWQuDQoNClRoaXMg d2FzIHRoZSBsYXN0IGludGVyaW0gcGxhbm5lZCwgbmV4dCBtZWV0aW5nIGlzIHRoZSBmMmYgaW4g UHJhZ3VlLiBIb3BlIHRvIHNlZSB5b3UgYWxsIHRoZXJlIQ0KDQpUaGFua3MsDQpGcmFuY2VzY2EN Cg0KLS0NCg0KQ0JPUiBXRyBDb25mZXJlbmNlIENhbGwNCldlZG5lc2RheSwgTWFyIDEzIDIwMTks IDE4OjAwIC0gMTk6MDAgVVRDDQpDaGFpcnM6IEJhcnJ5IExlaWJhLCBGcmFuY2VzY2EgUGFsb21i aW5pDQoNCk1pbnV0ZSB0YWtlcnM6IEZyYW5jZXNjYQ0KDQpQYXJ0aWNpcGFudHM6DQoqIEZyYW5j ZXNjYSBQYWxvbWJpbmkNCiogQ2Fyc3RlbiBCb3JtYW5uDQoqIEppbSBTY2hhYWQNCiogSmVmZnJl eSBZYXNza2luDQoNClJlZ3JldHM6DQoqIEJhcnJ5IExlaWJhDQoqIFBhdWwgSG9mZm1hbg0KDQoN CiogQ0RETCBTdGF0dXM6DQogICAgLSBjaGFpcnMgdG8gcGluZyBFS1INCiAgICAtIGFzayBBbGV4 ZXkgdG8gcHJlcGFyZSB0aGUgQUQgZm9sbG93IHVwDQogICAgDQoqIENCT1IgQmlzIHN0YXR1cw0K CUludGVncmF0ZWQgMi8zIG9mIDE3LiBKZWZmcmV5IHByb3Bvc2VzIHRvIGRlbGV0ZSBhIGxvdCBv ZiB0ZXh0LCBzdGlsbCBjaGVja2luZyAtPiBQUjYxDQoJSmVmZnJleSBwcm92aWRlZCBmZWVkYmFj aw0KCUplZmZyZXk6IGFncmVlcyBvbiB0aGUgbWVyZ2VkIHNvIGZhci4NCglQUi0gYW5kIElzc3Vl LWxlc3Mgc3RhdGUgYnkgUHJhZ3VlLiBTdWJtaXQgYSBuZXcgdmVyc2lvbiBhdCB0aGUgc3RhcnQg b2YgdGhlIG1lZXRpbmcuIEdldCBtb3JlIHJldmlld3MuDQoJbmVlZHMgdG8gYmUgY2hlY2tlZDoN CgkqIHN0cmljdCBkZWNvZGVyDQoJKiBkZXRlcm1pbmlzdGljIGVuY29kaW5nDQoNCiogYXJyYXkg dGFnczoNCglHb29kIGZlZWRiYWNrLCBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkLCB0byBpbnRlZ3Jh dGUuIElzc3VlcyBub3QgYWRyZXNlZDoNCgktIGhvdyBkb2VzIGRldGVybWluaXN0aWMgZW5jb2Rp bmcgd29ya3Mgd2l0aCBhcnJheSB0YWdzPyBpdCBpcyBub3Qgc29tZXRoaW5nIHRoYXQgd2UgbmVl ZCB0byBhZGRyZXNzIChhcHBsaWNhdGlvbiBhc3BlY3QpDQoJSmVmZnJleTogZGV0ZXJtaW5pc3Rp YyBlbmNvZGluZyBhdCB0aGUgcHJvdG9jb2wgbGV2ZWwNCglKaW06IGFncmVlDQoJLSBtb3N0IG9m IEppbSdzIGNvbW1lbnRzIGVkaXRvcmlhbCwgZXhjZXB0IGZvciBxdWVzdGlvbnMgYWJvdXQgY2xh bXBlZCBhcnJheXMNCglKZWZmcmV5OiA2IGFuZCA3IG5vdCBmdWxseSBhbnN3ZXJlZC4gQm90aCBv ZiB0aG9zZSBuZWVkIGEgZGVzY3JpcHRpb24gb2YgdGhlIHVzZSBjYXNlcw0KCUNhcnN0ZW46IG9r DQoJSmltOiBhZ3JlZSwgd2Fzbid0IGNsZWFyIHdoYXQgeW91IHdlcmUgdXNpbmcgdGhhdCBmb3IN Cg0KKiBPSUQgdGFnOg0KCS0gbm8gcHJvZ3Jlc3MNCgktIENhcnN0ZW46IGhhcyBhIGxvdCBvZiB0 aGluZ3MgdGhhdCB3YXMgbm90IG1lYW50IHRvIGJlIGluIGl0LCBpdCBtaWdodCBiZSBnb29kIHRv IHNlcGFyYXRlIHRoZSBiYXNpY3M6IG9ubHkgT0lEcyBpbiBpdA0KCS0gMSswIC0+IHN0YXJ0IGlu IHRoZSBtYWlsaW5nIGxpc3QNCg0KKiByZS1jaGFydGVyaW5nIC0+IGFkZCB0byBhZ2VuZGENCglD YXJzdGVuOiBDRERMIDIuMCwgdGFncywgY2Jvci1zZXEgKHNlZSBzbGlkZXMgZnJvbSBwcmV2aW91 cyBtZWV0aW5nKQ0KCUNhcnN0ZW4gdG8gc2VuZCBpbiBhZ2VuZGEgc2xvdCByZXF1ZXN0cyBmb3Ig aXRlbXMgY2FuZGlkYXRlIGZvciByZWNoYXJ0ZXJpbmcuDQoNCu+7v09uIDEzLzAzLzIwMTksIDE4 OjExLCAiQ0JPUiBvbiBiZWhhbGYgb2YgRnJhbmNlc2NhIFBhbG9tYmluaSIgPGNib3ItYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+ IHdyb3RlOg0KDQogICAgUmVtaW5kZXI6IFRoZSBuZXh0IENCT1IgdGVsZWNvbmZlcmVuY2UgaXMg aW4gNTAgbWludXRlcy4NCiAgICANCiAgICBXZWJleDoNCiAgICBodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tZjMxYjhlNjNjZmQzNTRjYTg0NjFiOTk4YWEzMGM0YmEgDQog ICAgDQogICAgVGFsayB0byB5b3Ugc29vbiwNCiAgICBGcmFuY2VzY2ENCiAgICANCiAgICBPbiAw My8xMi8yMDE4LCAxODozMSwgIkNCT1Igb24gYmVoYWxmIG9mIElFU0cgU2VjcmV0YXJ5IiA8Y2Jv ci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4g d3JvdGU6DQogICAgDQogICAgICAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50 YXRpb24gTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgKGNib3IpIFdvcmtpbmcgR3JvdXAgd2ls bCBob2xkDQogICAgICAgIGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gMjAxOS0wMy0xMyBm cm9tIDE4OjAwIHRvIDE5OjAwIFVUQy4NCiAgICAgICAgDQogICAgICAgIFRoZSBDQk9SIHdvcmtp bmcgZ3JvdXAgd2lsbCBoYXZlIGNvbmZlcmVuY2UgY2FsbHMgcnVubmluZyBldmVyeSB0d28gd2Vl a3MgdGhyb3VnaCB0aGUgZW5kIG9mIE1hcmNoICh1bnRpbCBJRVRGIDEwNCBpbiBQcmFndWUpLiAg IA0KICAgICAgICBEYXk6IGV2ZXJ5IG90aGVyIFdlZG5lc2RheSBiZWdpbm5pbmcgb24gMTkgRGVj ZW1iZXIgDQogICAgICAgIERhdGVzOiAxOSBEZWM7IDIsIDE2LCAzMCBKYW47IDEzLCAyNyBGZWI7 IDEzIE1hcmNoIA0KICAgICAgICBUaW1lOiAxODowMCB0byAxOTowMCBVVA0KICAgICAgICANCiAg ICAgICAgQWdlbmRhOg0KICAgICAgICAoTm8gYWdlbmRhIHN1Ym1pdHRlZCkNCiAgICAgICAgDQog ICAgICAgIEluZm9ybWF0aW9uIGFib3V0IHJlbW90ZSBwYXJ0aWNpcGF0aW9uOg0KICAgICAgICBX ZSB3aWxsIHVzZSB0aGUgd29ya2luZyBncm91cCBXZWJFeCBmb3IgdGhlIGNhbGxzLiAgVGhlIElF VEYgV2ViRXggYWNjb3VudCBkb2VzIG5vdCBhbGxvdyBJbnRlcm5hdGlvbmFsIGRpYWxpbmcgbm9y IFVTIHRvbGwgZnJlZSAoIjgwMCIgbnVtYmVycyksIGJ1dCB5b3UgY2FuIHVzZSB0aGUgV2ViRXgg YXBwIHRvIGNvbm5lY3QgeW91ciBkZXZpY2UgYXVkaW8sIGFuZCB0aGVyZSdzIGFsc28gdGhlIG9w dGlvbiBvZiBjb25uZWN0aW9uIGRpcmVjdGx5IGZyb20geW91ciBicm93c2VyIGlmIHlvdXIgYnJv d3NlciBzdXBwb3J0cyBpdC4gIFdlYkV4IGRldGFpbHMgd2lsbCBiZSBzZW50IHRvIHRoZSBtYWls aW5nIGxpc3QgYmVmb3JlIGVhY2ggY2FsbCAodGhlIGRldGFpbHMgd2lsbCBiZSB0aGUgc2FtZSBm b3IgYWxsIGNhbGxzLCBidXQgdGhlIG1lc3NhZ2VzIHdpbGwgc2VydmUgYXMgcmVtaW5kZXJzKS4N CiAgICAgICAgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgICAgIENCT1IgbWFpbGluZyBsaXN0DQogICAgICAgIENCT1JAaWV0Zi5v cmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQog ICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgDQoNCg== From nobody Thu Mar 14 18:49:16 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A31130EED; Thu, 14 Mar 2019 18:49:10 -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, 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 WXRs4wpWDeiz; Thu, 14 Mar 2019 18:49:06 -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 F3E6F1311F8; Thu, 14 Mar 2019 18:49:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 18:49:00 -0700 From: Jim Schaad To: 'Jeffrey Yasskin' , 'Laurence Lundblade' CC: , , 'Francesca Palombini' References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <6F7C83DD-E98C-44EF-A315-194E31759518@island-resort.com> <72F7B17A-2684-4591-8D70-01DE32BFA03B@island-resort.com> In-Reply-To: Date: Thu, 14 Mar 2019 18:48:56 -0700 Message-ID: <00eb01d4dad1$42493120$c6db9360$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01D4DA96.95EC06D0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJDckXT1PNyaRbuIeGp9sN/08XZzALTp86QAZld6+8Cj9y01qT21eGw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 01:49:14 -0000 ------=_NextPart_000_00EC_01D4DA96.95EC06D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would say that this is analogous to the question of how date and time = are encoded. There are several different options and we don=E2=80=99t = say which of them is deterministic for encoding. We just say how to = encode it once the value and tag are selected. =20 Jim =20 =20 From: CBOR On Behalf Of Jeffrey Yasskin Sent: Wednesday, March 13, 2019 11:29 AM To: Laurence Lundblade Cc: cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org; Francesca = Palombini Subject: Re: [Cbor] =F0=9F=94=94 WGLC on draft-ietf-cbor-array-tags-03 =20 On Fri, Mar 8, 2019 at 7:43 AM Laurence Lundblade > wrote: In addition to what I said before, a deterministic encoding should be = specified (formerly known as canonical) in the specification and that = should probably be network / big endian. =20 I think it's the job of the protocol to describe how it's encoded = deterministically, rather than this tag. For example, the choice of = whether or not to tag an array at all is a potential point for = non-determinism to enter, so the protocol needs to specify whether = there's a tag, and if so, which one. At that point, it's made the choice = of little-vs-big endian, so there's no more question for this document = to answer. =20 Jeffrey ------=_NextPart_000_00EC_01D4DA96.95EC06D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I would = say that this is analogous to the question of how date and time are = encoded.=C2=A0 There are several different options and we don=E2=80=99t = say which of them is deterministic for encoding.=C2=A0 We just say how = to encode it once the value and tag are selected.

 

Jim

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Jeffrey = Yasskin
Sent: Wednesday, March 13, 2019 11:29 AM
To: = Laurence Lundblade <lgl@island-resort.com>
Cc: = cbor@ietf.org; draft-ietf-cbor-array-tags@ietf.org; Francesca Palombini = <francesca.palombini@ericsson.com>
Subject: Re: [Cbor] = 🔔 = WGLC on draft-ietf-cbor-array-tags-03

 

On = Fri, Mar 8, 2019 at 7:43 AM Laurence Lundblade <lgl@island-resort.com> = wrote:

In = addition to what I said before, a deterministic encoding should be = specified (formerly known as canonical) in the specification and that = should probably be network / big = endian.

 

I = think it's the job of the protocol to describe how it's encoded = deterministically, rather than this tag. For example, the choice of = whether or not to tag an array at all is a potential point for = non-determinism to enter, so the protocol needs to specify whether = there's a tag, and if so, which one. At that point, it's made the choice = of little-vs-big endian, so there's no more question for this document = to answer.

 

Jeffrey

------=_NextPart_000_00EC_01D4DA96.95EC06D0-- From nobody Fri Mar 15 06:24:47 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBB413124B; Fri, 15 Mar 2019 06:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GByINxqkxJTm; Fri, 15 Mar 2019 06:24:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C7813124A; Fri, 15 Mar 2019 06:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1066; q=dns/txt; s=iport; t=1552656277; x=1553865877; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=x/pfRlB7shU4Fo6lrLTfZVmHCxwNHeU8fbYRNyCoAfg=; b=ARZ1PxoE6SGDzDPqC0Kco59DqLSql7jqhYCvCyQcG9nJzMlw6vAr5/6t WyKxqs3mFQZk2ha3UZDyPlvBkAAp3F3uhaOO934zN2Jcz9lMdlCE7p3gT 4+/iZJVrHqXMrn3txojwpqFRCcWbDKi+jtEFunQpgJ62tdnFVEsfCZdA1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAC8potc/5tdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCD4FrJwqZS5gxgXsLAQGBd4J1AoRQIjUIDQE?= =?us-ascii?q?BAwEBCQEDAm0ohUoBAQEEOksEAgEIEQQBAR8QMh0IAgQBEgiFEK0sijaBLwG?= =?us-ascii?q?LMheBQD+BEYMSimIDpEoJApMZIZNQiwWSdQIRFYEoIAE2gVZwFYMnghYXjh5?= =?us-ascii?q?BMY1fgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,482,1544486400"; d="scan'208";a="532585225" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 13:24:36 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2FDOZbb025558 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2019 13:24:35 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Mar 2019 08:24:35 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 15 Mar 2019 08:24:35 -0500 From: "Rob Wilton (rwilton)" To: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" Thread-Topic: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 Thread-Index: AQHU0if+rkpVL8iC4E+Vyl/vbXGKcaYMvJmQ Date: Fri, 15 Mar 2019 13:24:35 +0000 Message-ID: <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> References: <21467.1551662213@localhost> In-Reply-To: <21467.1551662213@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.63.23.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Cbor] [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 13:24:40 -0000 I think that it would be good if these drafts could somehow progress to com= pletion. I've previously posted comments on the SID draft, but never received any re= sponse. In short, I think that it would be more pragmatic if SIDs are restricted to= the non-negative range of the signed 64 bit integer type. I.e. disallow v= alues from (2^63 through 2^64 - 1). Thanks, Rob=20 -----Original Message----- From: core On Behalf Of Michael Richardson Sent: 04 March 2019 01:17 To: cbor@ietf.org; core@ietf.org Subject: [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 I wonder if these two drafts wouldn't be better off in CBOR WG? draft-ietf-core-sid-05 YANG Schema Item iDentifier (SID) draft-ietf-core-yang-cbor-07 CBOR Encoding of Data Modeled with YANG Well, anything that would allow the SID to progress enough for the registri= es to be created so that they can be used. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Mar 15 08:42:53 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFFC13126B; Fri, 15 Mar 2019 08:42:42 -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 uum3ZGLBHoyV; Fri, 15 Mar 2019 08:42:40 -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 03AD913126E; Fri, 15 Mar 2019 08:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x2FFgNCc015386; Fri, 15 Mar 2019 16:42:28 +0100 (CET) Received: from [IPv6:2001:638:708:30da:350e:7c7:5611:1727] (unknown [IPv6:2001:638:708:30da:350e:7c7:5611:1727]) (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 44LVFW09Txz1Bp8; Fri, 15 Mar 2019 16:42:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> Date: Fri, 15 Mar 2019 16:42:22 +0100 Cc: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 574357340.568283-b6ec990e683caf938bd49d9f38306dc1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21467.1551662213@localhost> <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:42:46 -0000 On Mar 15, 2019, at 14:24, Rob Wilton (rwilton) = wrote: >=20 > In short, I think that it would be more pragmatic if SIDs are = restricted to the non-negative range of the signed 64 bit integer type. = I.e. disallow values from (2^63 through 2^64 - 1). SIDs are unsigned integers. However, there are still languages that = have a hard time with those. And it helps if all SID deltas fit into a = signed 64-bit integer. So maybe limiting SIDs to the (non-negative) range of signed 64-bit = integers is a restriction that makes sense. https://github.com/core-wg/yang-cbor has three pull requests, but no = issues. (This apparently also happens to be the repo for the SID specification.) Should we put up the issues there? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 15 10:47:49 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA512958B; Fri, 15 Mar 2019 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 LPk8qtgPEeyl; Fri, 15 Mar 2019 10:47:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7CB1277D7; Fri, 15 Mar 2019 10:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1552672058; x=1553881658; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3lPx2Tw2JkEIxFjXbKx22BzIVTdgbmA3dJZP9lO/i00=; b=Jeich92I9yh2amNqQY2uRyo6/f4Fytru9C3XbWzndSKeUrZEcCd+qyd9 028jubZFr6YrAWGrpmGlCOFwWg2Haqt0b0rW26jL5Eh5Rtss2FhxmkgNP h7xzzANcpDFANL/q66Aa6ndRotchrKFgmU2PAaj189CivD/dROralBLHy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAX5Itc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWCBF1AzJ4QLiHuMIi2YMYF7DR+ETQK?= =?us-ascii?q?EcjYHDQEBAwEBCQEDAm0cDIVKAQEBAwEjDwEFQQULCQIOCgICJgICVwYBDAY?= =?us-ascii?q?CAQGDHgGBbQgPj3KbZoEvhDABgRWEawWBCyQBi0mBQD+BOIJrgx4ChGuCVwO?= =?us-ascii?q?kSgmHW4tCBhmLDIhEiwWFdYVfh0mBTgMugVYzGggbFYMnghYXg0uFFIU/PwM?= =?us-ascii?q?wjnsBAQ?= X-IronPort-AV: E=Sophos;i="5.58,482,1544486400"; d="scan'208";a="10709012" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2019 17:47:35 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2FHlZKf019804; Fri, 15 Mar 2019 17:47:35 GMT To: Carsten Bormann , draft-ietf-core-sid@ietf.org Cc: Michael Richardson , "cbor@ietf.org" , "core@ietf.org" References: <21467.1551662213@localhost> <92df97c1457947f09a2de92d740de925@XCH-RCD-007.cisco.com> From: Robert Wilton Message-ID: <7809a821-7ea8-f6ff-b5ff-ea8b124f9941@cisco.com> Date: Fri, 15 Mar 2019 17:47:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.135, dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Cbor] [core] draft-ietf-core-sid-05 and draft-ietf-core-yang-cbor-07 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 17:47:43 -0000 On 15/03/2019 15:42, Carsten Bormann wrote: > On Mar 15, 2019, at 14:24, Rob Wilton (rwilton) wrote: >> In short, I think that it would be more pragmatic if SIDs are restricted to the non-negative range of the signed 64 bit integer type. I.e. disallow values from (2^63 through 2^64 - 1). > SIDs are unsigned integers. However, there are still languages that have a hard time with those. I imagine that you may be referring to languages like Java and Python, but in my experience, C and C++ also struggle to safely use unsigned numbers. E.g. https://blog.regehr.org/archives/268 and their similar cases. > And it helps if all SID deltas fit into a signed 64-bit integer. This is really the key one for me. Otherwise, I would guess that many implementations will probably just assume that the delta always fits into a signed 64-bit integer and potentially fail silently in the future when they hit an overflow/underflow condition. > So maybe limiting SIDs to the (non-negative) range of signed 64-bit integers is a restriction that makes sense. > > https://github.com/core-wg/yang-cbor has three pull requests, but no issues. > (This apparently also happens to be the repo for the SID specification.) > > Should we put up the issues there? I've added the author alias.  Hopefully we'll get an answer. Thanks, Rob > > Grüße, Carsten > > . > From nobody Mon Mar 18 03:22:48 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BDA130ED1 for ; Mon, 18 Mar 2019 03:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=UWB4mBs5; dkim=pass (1024-bit key) header.d=ericsson.com header.b=by1aJki8 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 LzFbZY_zgW2Q for ; Mon, 18 Mar 2019 03:22:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 66E3C128D7A for ; Mon, 18 Mar 2019 03:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552904561; x=1555496561; 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=/tHntzV4UcJbg4xzrF+VYOWQmGtVN5Y+0ghCV7LSBrU=; b=UWB4mBs5iTO1ZmCle819Ty2PaDPI5M7AP3uaBLBBrTbZ7FkUMXYJb0C5Zg2ZLcvq rddZ05+/jkILzFkLKfDVj8KE7xfFLFQqVEnHLNNzDQOFpGfmMtnwkWkA2E390fug HBNcYJKKuET0yxqlQiPY6Dl5XlfEPkkkd/TDTkT4R0A=; X-AuditID: c1b4fb2d-d9dff7000000062f-65-5c8f71710477 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E9.6B.01583.1717F8C5; Mon, 18 Mar 2019 11:22:41 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 18 Mar 2019 11:22:41 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 18 Mar 2019 11:22:41 +0100 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=/tHntzV4UcJbg4xzrF+VYOWQmGtVN5Y+0ghCV7LSBrU=; b=by1aJki8/z7c3R9ZVLG2pL6ml0zodc0C2vl/15W+Fh/0Ucr3258ORTKc7zkpGLNzVWdinJRysjlrTYdgMeafA2C53+lkF0WB5j/jezFNmSIoPm0q6X3hBt0PqIzx23F3brllAnRBMtkewGCKj6ApFtvvAE91ge5TDVfnJq7K2eg= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2563.eurprd07.prod.outlook.com (10.173.92.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.8; Mon, 18 Mar 2019 10:22:40 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::e9a3:96b9:7bd3:bf12]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::e9a3:96b9:7bd3:bf12%4]) with mapi id 15.20.1709.015; Mon, 18 Mar 2019 10:22:40 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot request for IETF 104 Thread-Index: AQHU2K6XOVncETbstUWlLwJrndh/tKYRSG2A Date: Mon, 18 Mar 2019 10:22:40 +0000 Message-ID: <787962E7-3AEF-42B9-A8E0-B6A7F2A538C5@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2cb10ba-ad5b-4baf-1548-08d6ab8ba688 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2563; x-ms-traffictypediagnostic: AM5PR0701MB2563: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(136003)(376002)(396003)(53754006)(189003)(199004)(2906002)(97736004)(6506007)(6916009)(186003)(11346002)(316002)(486006)(14444005)(6306002)(44832011)(3846002)(450100002)(6116002)(36756003)(66066001)(5640700003)(68736007)(476003)(102836004)(229853002)(6346003)(6486002)(6246003)(6512007)(6436002)(53936002)(86362001)(26005)(2616005)(446003)(53546011)(2351001)(1730700003)(106356001)(33656002)(105586002)(478600001)(8936002)(14454004)(99286004)(966005)(71200400001)(82746002)(256004)(5660300002)(7736002)(83716004)(71190400001)(2501003)(81166006)(8676002)(25786009)(4326008)(81156014)(76176011)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2563; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KeJT6EGjx5DLFipC73a/N5EhsbxXamPb9VAD2H/qa5Ori4tukT6qcogKTyXazZZWA2rYzBz7/fvs5G5SowE+hXJhUP9xCsQQxJMY24cqfRcvCIXryDmcVC6t/NpardVuvESUcErhIP4wMoiMA0MYlX/lAizLFzLIl2VHm8KpZfOlwjZlc55CQTrmC7dLumrxrl0dp3w/mFchxzJ0FfmMC6de/jouOc4E4z6qex8ISmFBKRx275/Il0pV3Y3DV7y1QEgxSMvppmOBe6e8JVUA0uKrdBwUWrGiC7VZid23UI6KjCQx6b942x8hAwJn/9/bWqyWQt1A3gFlz2cRaQXVAD0Kbo6nHd/25rZAXZ8C93nruiCces/3YtGJKVkf8djGoHghFLc4JXW4g1tIA897iClP/uUx02anszRv2FdWWxs= Content-Type: text/plain; charset="utf-8" Content-ID: <6AA66D06CA2460499600A09F63727CC2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2cb10ba-ad5b-4baf-1548-08d6ab8ba688 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 10:22:40.0912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2563 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42KZGbG9WLewsD/GoPWglMXsv1sYLWZ2TGdx YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGp/WPGAuOyFdsOz+dvYHxjlwXIyeHhICJxJsHj5i7 GLk4hASOMEp0vD7JAuF8Y5R4vr8VylnCJLFw4l6wMhaBCcwSVw5MZYPITGWS6D61Hsp5xijR evQmC8hkNgEbiQsP37OC2CICyhJTpxwGKuLgYBYwlPi5pxAkLCygJtHzbh8jRIm6xIQj/9kg bCOJ5593sIPYLAKqEnvaN4ON4RWwl+iYNgWsRgjIvnHnJFgvp4CDRH/bFbAaRgFZiS+Nq5lB bGYBcYlbT+YzQTwqILFkz3lmCFtU4uXjf6wQtoLEq+4GNghbVuLS/G5GCNtX4vOEdUwgf0kI 3GaUOLN0BVSDjsSjn3NZIGwpif2b50E15Euc+LwBapCMxOUTC6Gat7NJvNy8mhHi6lSJ5Wtb GSEuTZa4cruPfQKj3iwkx84Ch5GmxPpd+hBhD4ll686xQtiKElO6H7LPAoeFoMTJmU9YFjCy rmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQITCMHt/zW3cG4+rXjIUYBDkYlHl7hzP4YIdbE suLK3EOMEhzMSiK89p5AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rx/hARjhATSE0tSs1NTC1KL YLJMHJxSDYwiE9xKeuZ1z7oW98Nyz5RN+4Q02hirPi17przpRc1aw3m7cgMtUyeV1FZLmtlP uTDfrcfohsWC7X3ZT9Ml1jyeusJJuUmT695tX476lz/5Zyytiqyc5vytKMYz/o6M6XG3mTuU nCOZ73+NP+XKtoT3jmv9lFjHme76YuxqSskifPqKDWomxkosxRmJhlrMRcWJAOLtZr0fAwAA Archived-At: Subject: Re: [Cbor] Slot request for IETF 104 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 10:22:47 -0000 SGkgYWxsLA0KDQpBIGRyYWZ0IGFnZW5kYSBmb3IgSUVURjEwNCB3YXMgdXBkYXRlZCB0byB0aGUg ZGF0YXRyYWNrZXI6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0 ZXJpYWxzL2FnZW5kYS0xMDQtY2Jvci0wMC50eHQNCg0KUGxlYXNlIGxldCB1cyBjaGFpcnMga25v dyBpZiB5b3UgaGF2ZSBhbnkgZmVlZGJhY2sgYWJvdXQgdGltZXNsb3RzLCBhbmQgaWYgeW91J2Qg bGlrZSB0byBhZGQgKG9yIHJlbW92ZSkgaXRlbXMuDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KLS0N Cg0KQ0JPUiBXRyBNZWV0aW5nDQpJRVRGIDEwNCAtIFByYWd1ZQ0KVGh1cnNkYXksIE1hciAyOCwg MjAxOSwgMDk6MDAgLSAxMDozMA0KQ2hhaXJzOiBCYXJyeSBMZWliYSwgRnJhbmNlc2NhIFBhbG9t YmluaQ0KDQoNCiogSW50cm9kdWN0aW9uIFsxMCddIDogQ2hhaXJzDQogIEFnZW5kYSBiYXNoaW5n IGFuZCBXRyBzdGF0dXMgdXBkYXRlDQoNCldHIGRvY3VtZW50czoNCg0KKiBDRERMIFs1J10gOiBD aGFpcnMNCiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1jZGRs DQoNCiogQ0JPUiBzcGVjaWZpY2F0aW9uIHN0YXR1cyBbMzAnXSA6IENhcnN0ZW4NCiAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci03MDQ5YmlzDQoNCiogQ0JPUiBB cnJheSBUYWcgWzE1J10gOiBDYXJzdGVuDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNib3ItYXJyYXktdGFncw0KDQpPdGhlcjoNCg0KKiBOZXh0IHN0ZXAgZm9yIHRo ZSBXRyAoY2hhcnRlciBkaXNjdXNzaW9uKSBbMTUnXSA6IENoYWlycyAvIGFsbA0KDQoqIEZsZXh0 aW1lIFsxMCddDQoNCiogV3JhcC11cCBbNSddIDogQ2hhaXJzDQoNCu+7v09uIDEyLzAzLzIwMTks IDA5OjM2LCAiRnJhbmNlc2NhIFBhbG9tYmluaSIgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nz b24uY29tPiB3cm90ZToNCg0KICAgIEhpIGFsbCwNCiAgICANCiAgICBJZiB5b3Ugd291bGQgbGlr ZSB0byBoYXZlIGEgcHJlc2VudGF0aW9uIHNsb3QgZHVyaW5nIG91ciBtZWV0aW5nIGluIFByYWd1 ZSwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cuDQogICAgDQogICAgVGhhbmtzLA0KICAgIEZy YW5jZXNjYQ0KICAgIA0KICAgIE9uIDAxLzAzLzIwMTksIDIyOjEwLCAiIklFVEYgU2VjcmV0YXJp YXQiIiA8YWdlbmRhQGlldGYub3JnPiB3cm90ZToNCiAgICANCiAgICAgICAgRGVhciBGcmFuY2Vz Y2EgUGFsb21iaW5pLA0KICAgICAgICANCiAgICAgICAgVGhlIHNlc3Npb24ocykgdGhhdCB5b3Ug aGF2ZSByZXF1ZXN0ZWQgaGF2ZSBiZWVuIHNjaGVkdWxlZC4NCiAgICAgICAgQmVsb3cgaXMgdGhl IHNjaGVkdWxlZCBzZXNzaW9uIGluZm9ybWF0aW9uIGZvbGxvd2VkIGJ5DQogICAgICAgIHRoZSBv cmlnaW5hbCByZXF1ZXN0LiANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICAgICAgY2JvciBT ZXNzaW9uIDEgKDI6MDAgcmVxdWVzdGVkKQ0KICAgICAgICAgICAgVGh1cnNkYXksIDI4IE1hcmNo IDIwMTksIE1vcm5pbmcgU2Vzc2lvbiBJIDA5MDAtMTAzMA0KICAgICAgICAgICAgUm9vbSBOYW1l OiBLYXJsaW4gMyBzaXplOiA2MA0KICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgaUNhbGVu ZGFyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L3Nlc3Npb25zL2Ni b3IuaWNzDQogICAgICAgIA0KICAgICAgICBSZXF1ZXN0IEluZm9ybWF0aW9uOg0KICAgICAgICAN CiAgICAgICAgDQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICBXb3JraW5nIEdyb3VwIE5hbWU6IENvbmNpc2Ug QmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucw0K ICAgICAgICBBcmVhIE5hbWU6IEFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWENCiAgICAg ICAgU2Vzc2lvbiBSZXF1ZXN0ZXI6IEZyYW5jZXNjYSBQYWxvbWJpbmkNCiAgICAgICAgDQogICAg ICAgIE51bWJlciBvZiBTZXNzaW9uczogMQ0KICAgICAgICBMZW5ndGggb2YgU2Vzc2lvbihzKTog IDIgSG91cnMNCiAgICAgICAgTnVtYmVyIG9mIEF0dGVuZGVlczogNTANCiAgICAgICAgQ29uZmxp Y3RzIHRvIEF2b2lkOiANCiAgICAgICAgIEZpcnN0IFByaW9yaXR5OiBhcnRhcmVhIGRpc3BhdGNo IHNlY2Rpc3BhdGNoIHNhYWcgZXh0cmEgam1hcCB1dGEgZG1hcmMgaWFzYTIgY29yZSBhY2UgdDJ0 cmcgY29zZQ0KICAgICAgICAgU2Vjb25kIFByaW9yaXR5OiBzdWl0IGx3aWcgYW5pbWEgNnRpc2No DQogICAgICAgICBUaGlyZCBQcmlvcml0eTogYWNtZSByb2xsIGRldG5ldCBzYWNtIGxwd2FuIGRv dHMNCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBQZW9wbGUgd2hvIG11c3QgYmUgcHJlc2Vu dDoNCiAgICAgICAgICBDYXJzdGVuIEJvcm1hbm4NCiAgICAgICAgICBCYXJyeSBMZWliYQ0KICAg ICAgICAgIEFsZXhleSBNZWxuaWtvdg0KICAgICAgICAgIEZyYW5jZXNjYSBQYWxvbWJpbmkNCiAg ICAgICAgDQogICAgICAgIFJlc291cmNlcyBSZXF1ZXN0ZWQ6DQogICAgICAgIA0KICAgICAgICBT cGVjaWFsIFJlcXVlc3RzOg0KICAgICAgICAgIFBsZWFzZSBhdm9pZCBjb25mbGljdCB3aXRoIEFS VCBhbmQgSW9ULXJlbGF0ZWQgQm9Gcw0KICAgICAgICANCiAgICAgICAgUGxlYXNlIGF2b2lkIEZy aWRheTogb25lIGNoYWlyIGhhcyB0byBsZWF2ZSBvbiBlYXJseSBGcmlkYXkgbW9ybmluZw0KICAg ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICAgICAgDQogICAgICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Wed Mar 20 10:59:56 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DDC1311CF for ; Wed, 20 Mar 2019 10:59:44 -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 Zgrjl3bvVYmm for ; Wed, 20 Mar 2019 10:59:41 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41491311F9 for ; Wed, 20 Mar 2019 10:59:41 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 6fV5hchXDHni16fV6hhtCm; Wed, 20 Mar 2019 10:59:40 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_E6862165-14D1-48C6-9731-B991570DDEF4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 20 Mar 2019 10:59:39 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfOMgWz2nVWUpkO2PU+x9FRAH0JUVciaIiSAOLMx9YDOuLwiU4RNrEraGs5BqFXBiu1k5AXUzfeB6pYrXzrKkvvJFPk9tvSvEng+bpwwmheCSviPodSue n8zcZinHd1TLrz/0WZehotLWKE+VVAA56QpJ9afZSpjPl6KDn032yAso Archived-At: Subject: [Cbor] Handling malicious CBOR input X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 17:59:54 -0000 --Apple-Mail=_E6862165-14D1-48C6-9731-B991570DDEF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Carsten described three levels of error handling here = : =E2=80=A2 well-formed (vs. syntactic error). Not well-formed is now MUST = NOT generate/accept. =E2=80=A2 valid (vs. semantic error). Protocol encoders now MUST = generate valid CBOR. =E2=80=A2 expected (vs. unexpected by application). This is = application-specific and often expressed in CDDL. The middle one is more or less strict mode by my understanding (checking = for valid/invalid CBOR). Strict mode still has a lot of text says it is = a particularly useful way to defend against malicious input. The seems = off to me. I think it has to be defended against at all three levels. Before I go off and try for a pull request, here=E2=80=99s what I was = thinking: The main focus on malicious input is section 9 Security Consideration. = It gets improved with a discussion of the three levels of error handling = and how each level must do their part.=20 Text is also added to section 9 that says malicious input is pervasive = and inevitable, that even in closed environments and walled gardens, = even signed and encrypted CBOR input can not be assumed to be safe. Then section 4.3 Syntax Errors mentions malicious input and references = section 9. I would also like to disallow =E2=80=9Ctake some other = action=E2=80=9D in this section. There is also a mention and reference to section 9 in 4.4 Other Decoding = Errors. The malicious input text in section 4.11 Strict Decoding Mode = would largely be moved to section 9 and there would be a reference to = section 9. LL= --Apple-Mail=_E6862165-14D1-48C6-9731-B991570DDEF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Carsten described = three levels of error handling here:
=E2=80=A2 well-formed (vs. syntactic error). Not well-formed is now = MUST NOT generate/accept.
=E2=80=A2 valid (vs. semantic error). Protocol encoders now MUST = generate valid CBOR.
=E2=80=A2 expected = (vs. unexpected by application). This is application-specific and often = expressed in CDDL.

The middle one is more or less strict = mode by my understanding (checking for valid/invalid CBOR). Strict mode = still has a lot of text says it is a particularly useful way to defend = against malicious input. The seems off to me. I think it has to be = defended against at all three levels.

Before I go off and try for a pull = request, here=E2=80=99s what I was thinking:

The main focus on malicious input is = section 9 Security Consideration.  It gets = improved with a discussion of the three levels of error handling and how = each level must do their part. 

Text is also added to section 9 that = says malicious input is pervasive and inevitable, that even in closed = environments and walled gardens, even signed and encrypted CBOR input = can not be assumed to be safe.

Then section 4.3 Syntax = Errors mentions malicious input and references section 9. I would = also like to disallow =E2=80=9Ctake some other action=E2=80=9D in this = section.

There = is also a mention and reference to section 9 in 4.4 Other = Decoding Errors. The malicious input text in section 4.11 Strict Decoding Mode would largely be moved to = section 9 and there would be a reference to section 9.

LL
= --Apple-Mail=_E6862165-14D1-48C6-9731-B991570DDEF4-- From nobody Wed Mar 20 11:27:06 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E0131200 for ; Wed, 20 Mar 2019 11:27:04 -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 DFM4qioKpcGY for ; Wed, 20 Mar 2019 11:27:02 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 93BC51310E0 for ; Wed, 20 Mar 2019 11:27:02 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id 6fvYhoPEgdwXW6fvZhLOon; Wed, 20 Mar 2019 11:27:01 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_F5710847-DC05-4A20-B878-DC9A9C1AD10B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 20 Mar 2019 11:27:00 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfBBWVQWFYpw/uWVKZ24TfkuY/XzTH6mAFhrDZczpKVuHozC8qeW3nvqa8CH7AgU59Ro7SSIqG/naBduUb3eAVG/5cx6j9G6m3J8dWKwOSU3IgS7IX4Ut SUjYpTGlGcyaYguoMrQThops7MC8z7K7C2SUcWep4WtgSmV5ZWU/39TP Archived-At: Subject: [Cbor] Strict mode X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 18:27:05 -0000 --Apple-Mail=_F5710847-DC05-4A20-B878-DC9A9C1AD10B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again, So strict mode seems to be the middle of these three: =E2=80=A2 well-formed (vs. syntactic error). Not well-formed is now MUST = NOT generate/accept. =E2=80=A2 valid (vs. semantic error). Protocol encoders now MUST = generate valid CBOR. =E2=80=A2 expected (vs. unexpected by application). This is = application-specific and often expressed in CDDL I went through the whole CBOR spec and identified almost 20 = valid/invalid checks that a decoder could perform. For example, valid = UTF-8, tag 1 dates are integer or float, key duplication, base64 uses = only allowed base64 characters, MIME data is valid MIME syntax=E2=80=A6 = Some of these are cheap, easy and obvious. Others are quite expensive = and difficult.=20 So strict mode seems somewhat of an implied smorgasbord of checks that a = generic decoder might perform or not perform. In many cases it will be = much cheaper and easier to implement these checks in the next layer up. = They might already be there too, so it would be waste for a generic = decoder to perform them. For example, a base64 encoder will probably = check for allowed base64 characters. I think it is kind of interesting to describe a CBOR firewall and that = such a thing might be useful. I think it is more than strict mode = though. It needs to check for well-formed CBOR. If it is generic it = should check for as many invalid things as possible. It should also be = described as a secondary defense and that the main decoder for a = protocol should never rely on it. See section 9. My thought for the document would be to list all of the almost 20 = valid/invalid checks in 4.4 Other Decoding Errors with some discussion = on how and when they might be implemented. Then remove mention of the = specific valid/invalid checks in 4.11 Strict Mode Decoding. That is kind = of duplicate text now. Then make section 4.11 about CBOR Firewalls. LL= --Apple-Mail=_F5710847-DC05-4A20-B878-DC9A9C1AD10B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = again,

So strict = mode seems to be the middle of these three:
=E2=80=A2 well-formed (vs. syntactic error). Not well-formed is now MUST NOT = generate/accept.
=E2=80=A2 valid (vs. semantic error). Protocol encoders now MUST generate = valid CBOR.
=E2=80=A2 expected (vs. unexpected by = application). This is application-specific and often expressed in = CDDL

I went through the whole CBOR spec and = identified almost 20 valid/invalid checks that a decoder could perform. = For example, valid UTF-8, tag 1 dates are integer or float, key = duplication, base64 uses only allowed base64 characters, MIME data is = valid MIME syntax=E2=80=A6  Some of these are cheap, easy and = obvious. Others are quite expensive and = difficult. 

So = strict mode seems somewhat of an implied smorgasbord of checks = that a generic decoder might perform or not perform. In many cases = it will be much cheaper and easier to implement these checks in the next = layer up. They might already be there too, so it would be waste for a = generic decoder to perform them. For example, a base64 encoder will = probably check for allowed base64 characters.

I think it is kind of interesting to describe a CBOR firewall and that such a thing might be useful. I = think it is more than strict mode though. It needs to check for = well-formed CBOR. If it is generic it should check for as many invalid = things as possible. It should also be described as a secondary defense = and that the main decoder for a protocol should never rely on it. See = section 9.

My= thought for the document would be to list all of the almost 20 = valid/invalid checks in 4.4 Other Decoding Errors with = some discussion on how and when they might be implemented. Then = remove mention of the specific valid/invalid checks in 4.11 = Strict Mode Decoding. That is kind of duplicate text now. Then make = section 4.11 about CBOR Firewalls.

LL
= --Apple-Mail=_F5710847-DC05-4A20-B878-DC9A9C1AD10B-- From nobody Sat Mar 23 21:02:54 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5166C130DD8; Sat, 23 Mar 2019 21:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: draft-ietf-cbor-cddl@ietf.org, Barry Leiba , cbor-chairs@ietf.org, barryleiba@computer.org, cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Eric Rescorla Message-ID: <155340017232.15684.3113249343504076642.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2019 21:02:52 -0700 Archived-At: Subject: [Cbor] Eric Rescorla's No Objection on draft-ietf-cbor-cddl-07: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 04:02:53 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-cbor-cddl-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS From nobody Sun Mar 24 06:16:11 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3761A12799B; Sun, 24 Mar 2019 06:16:10 -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 c-Co-LBHimN8; Sun, 24 Mar 2019 06:16:07 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49C612788C; Sun, 24 Mar 2019 06:16:06 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44RyZX2f2Zz100G; Sun, 24 Mar 2019 14:16:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> Date: Sun, 24 Mar 2019 14:16:03 +0100 Cc: The IESG , cbor@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org X-Mao-Original-Outgoing-Id: 575126161.9287961-eb886c4491f1e406f746468bea78c2c8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <154258532777.2578.8591857608340815014.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-cddl-05: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 13:16:10 -0000 Hi Benjamin, apologies for sitting on this for so long; it was masked for me by a = thread on one of the sub-issues. I=E2=80=99m preparing a -08 right now = to capture some of the finer points raised; this lives in = https://github.com/cbor-wg/cddl/pull/28 and in = https://cbor-wg.github.io/cddl/prepare-08/ =E2=80=94 the plan is to = submit this in the next hours as -08. > On Nov 19, 2018, at 00:55, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cbor-cddl-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for updating the editor's copy pursuant to the secdir review! >=20 > As I was reading, I wondered about potential confusion between a = numerical > value and the corresponding text string when used as a keytype, = especially > for barewords. The bareword ABNF requires a leading EALPHA, which = should > force the right parsing, while the memberkey ABNF still allows literal > values to be used as keys. I do wonder, though, if the 'id' ABNF's > limitations on textual names (i.e., strings that could be interpreted = as > numbers are disallowed) should be mentioned in the main text as how > disambiguation is enforced in general. For my taste, this is already covered by This is actually a complete example: an identifier that is followed by a colon can be directly used as the text string for a member key (we speak of a "bareword" member key), as can a double-quoted string or a number. (There indeed is an assumption that the reader is vaguely familiar with = programming language concepts such as =E2=80=9Cidentifiers=E2=80=9D.) > It's a little weird to use PersonalData as an example, given the = privacy > considerations inherent in storing personal data, but I guess this is = not > really a flaw in the spec. Textbooks that introduce data description formats tend to use these = examples; in hindsight you are right that we might be a bit off-script = here. > Section 1 >=20 > Nit: bullet (G3) lacks grammatical parallelism with its sibling = bullets; > something like =E2=80=9CBe able to" would restore parity. Fixed in -08. > Section 2 >=20 > 1. Instead of defining all four types of composition in CDDL > separately, or even defining one kind for arrays (vectors and > records) and one kind for maps (tables and structs), there is > only one kind of composition in CDDL: the _group_ (Section 2.1). >=20 > This perhaps reads a bit strongly, as we do go on to define syntactic = sugar > for arrays and maps, even though they build on the shared group > abstraction. The syntactic sugar essentially encapsulates groups, so I think the = statement is appropriate. > Section 2.1 >=20 > Note that the (curly) braces signify the creation of a map; the > groups themselves are neutral as to whether they will be used in a > map or an array. > [...] > Note that the lists inside the braces in the above definitions > constitute (anonymous) groups, while "identity" is a named group. >=20 > I might add another sentence in one of these places foreshadowing the > behavior that groups are "macro-like" the sense that when used in the > description of another group, their contents are siblings of the = elements > that are new in the other group, as opposed to being part of a nested > structure. -08 is now saying: Note that the lists inside the braces in the above definitions constitute (anonymous) groups, while `identity` is a named group, which can then be included as part of other groups (anonymous as in the example, or themselves named). It is a bit hard to explain the splicing nature of that (splicing as in = ,@) without confusing the people who would never expect there to be a = non-splicing version (as in ,); I think the context of the example = should make this clear enough. >=20 > Section 3.1 >=20 > o CDDL uses UTF-8 [RFC3629] for its encoding. >=20 > It's pretty rare for it to be sufficient to just say "UTF-8" in a = technical > spec; what kind of internationalization review has been done? Do we = need > to specify anything about normalization or canonicalization? We are not doing any of that, but could say explicitly so. So -08 now = says: * CDDL uses UTF-8 {{RFC3629}} for its encoding. Processing of CDDL does not involve Unicode normalization processes. > Section 3.5.1 >=20 > The "struct" usage of maps is similar to the way JSON objects are > used in many JSON applications. >=20 > A map is defined in the same way as defining an array (see > Section 3.4), except for using curly braces "{}" instead of square > brackets "[]". >=20 > Taken together, these paragraphs read as if (1) a struct is a type of = map, > and (2) a map uses curly brackets. But the following example shows a = struct > as enclosed within square brackets. Where am I going wrong? The text is indeed wrong. Sorry for not noticing this after all these = editing rounds. The sentence introducing the example now reads: The following is an example of a record with a structure embedded: And the sentence after it: When encoding, the Geography record is encoded using a CBOR array with two members (the keys for the group entries are ignored), whereas the GpsCoordinates structure is encoded as a CBOR map with two key/value pairs. >=20 > GpsCoordinates =3D { > longitude : uint, ; multiplied by 10^7 > latitude : uint, ; multiplied by 10^7 > } >=20 > It is perhaps irresponsible to include an example that does not = specify the > units of the measurement (e.g., degrees or radians). Yes,=20 GpsCoordinates =3D { longitude : uint, ; degrees, scaled by 10^7 latitude : uint, ; degreed, scaled by 10^7 } is better. Now in -08. > Section 3.8.6 >=20 > value from being sent over the wire. This control is only = meaningful > when the control type is used in an optional context; otherwise = there > would be no way to express the default value. >=20 > Maybe s/express/utilize/? That is, the ".default" control still = expresses > what the default value would be, but that information would never be = used. =E2=80=9Cmake use of=E2=80=9D now in -08. > Section 5 >=20 > o Where the CDDL includes extension points, the impact of = extensions > on the security of the system needs to be carefully considered. >=20 > Would it make sense to also add guidance for judicious use of .within = to > constrain extension points? Probably. The level of experience with the .within construct is not yet = very high, though, so maybe that is better addressed in another document = after a few more years of experience. > Writers of CDDL specifications are strongly encouraged to value > simplicity and transparency of the specification over its elegance. > Keep it as simple as possible while still expressing the needed data > model. >=20 > Perhaps "simplicity of [type] constructions", since some readers may = equate > simplicity [of design] and elegance. Maybe a better word for =E2=80=9Csimplicity=E2=80=9D here would be = =E2=80=9Cclarity=E2=80=9D. (The word =E2=80=9Csimple=E2=80=9D is then used in the second sentence.) I briefly thought about =E2=80=9Cplainness=E2=80=9D, but =E2=80=9Cclarity=E2= =80=9D is probably closest. > Section 6.1 >=20 > I don't really understand why there's a need for distinctions based on = the > presence of an internal dot, especially given that this document does = not > define any such operators. What would such a control operator look = like? At some point, we might want to namespace the control operators. E.g., = an SDO that needs control operators to peek into their proprietary data = formats might want to define a set of operators such as, say, .sdo.part1 .sdo.part2 if their data format has a part1 and a part2. We might want to control = such a namespacing process in a separate specification, that is why = these names are essentially reserved. > Section 7.2 >=20 > It seems that RFC 4648 might need to be a normative reference given = that it > specifies how some byte string literals are interpreted in EDN. (Indeed. This was fixed in -07.) > Appendix B >=20 > On first glance I wonder if some of the S should be 1*WS to avoid = parsing > ambiguities, but I did not think about it very hard. The one ambiguity I=E2=80=99m aware of that has been hit in practice is: 1..2 (range) one..two (single identifier) vs. one .. two (range) This is warned about in Section 2.2.2.1. Apart from that, we are assuming the usual greedy lexer for identifiers; = without that, there are many constructions such as foo=3Dbar=3Dint that parse ambiguously (it doesn=E2=80=99t parse at all with a greedy = lexer). (The ABNF has been made workable directly in a tool by applying parse = expression grammar semantics to it, which is what I would recommend to = anyone using ABNF.) We have since written Appendix A to discuss =E2=80=9Cambiguity=E2=80=9D = vs. =E2=80=9Cprioritized choice=E2=80=9D. > Note that this ABNF does not attempt to reflect the detailed rules = of > what can be in a prefixed byte string. >=20 > Before I made it this far, I was going to note that the "bytes" = definition > seems to allow me to use a "h" or b64" prefix with "arbitrary" = contents; it > seems that an alternate construction could embody the semantic = restrictions > for such strings into the ABNF. How bad would it be if a future = update to > this document attempted to actually reflect the "detailed rules of = what can > be in a prefixed byte string=E2=80=9D? I would love to write that piece of ABNF at some point, when I have = ample opportunities for debugging it=E2=80=A6 There are several = examples in RFCs for doing the exercise for (padded) base64; after the = insertion of a few S and removal of padding, that might work well here = as well. But nobody has done that work yet,=20 > Appendix D >=20 > I can't decide if most of the "#" entries need double-quotes around = them to > parse properly as ABNF. Is it best to think about this CBOR = major/minor > notation as an extension to standard ABNF? (Covered in a separate reply.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 24 07:59:13 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E7F130E62; Sun, 24 Mar 2019 07:59:06 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <155343954614.18094.10814805633104946109@ietfa.amsl.com> Date: Sun, 24 Mar 2019 07:59:06 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-cddl-08.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 14:59:06 -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 and JSON data structures Authors : Henk Birkholz Christoph Vigano Carsten Bormann Filename : draft-ietf-cbor-cddl-08.txt Pages : 62 Date : 2019-03-24 Abstract: This document proposes a notational convention to express CBOR data structures (RFC 7049, Concise Binary Object Representation). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-cddl-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 25 04:23:00 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA661203C3 for ; Mon, 25 Mar 2019 04:22:58 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 8gMfvBan2Whq for ; Mon, 25 Mar 2019 04:22:57 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB071203C2 for ; Mon, 25 Mar 2019 04:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1553512976; d=isode.com; s=june2016; i=@isode.com; bh=mKd4ygRb3P/PMoA55AgXTAZs5t2f3551i5B9pC+NTD0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LbNSwRY9ZhjMkAdMCmlSQQ6lf5m7QJzOB4gkEf41ZtoykOmBi+CCCtte6Y26m9CxjCiyoH ec7VAooleAeHfZr6yNcrQ1JJS1DQz5bZrNLaelMVKXpPabn8JIJxN2Pcz41aOi6pV+I1i6 y9DYT7Vk0/hfUWLpLAskVw/XkNg2tX4=; Received: from [31.133.128.237] (dhcp-80ed.meeting.ietf.org [31.133.128.237]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Mar 2019 11:22:56 +0000 To: cbor@ietf.org Cc: Jim Schaad , Barry Leiba From: Alexey Melnikov Openpgp: preference=signencrypt Message-ID: Date: Mon, 25 Mar 2019 11:22:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: [Cbor] CBOR co-chair change X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 11:22:58 -0000 Dear CBOR participants, With Barry Leiba being selected as another ART Area Director this WG needs a new co-chair for Francesca. I would like to thank Barry for his contributions! I am also pleased to announce that Jim Schaad has agreed to co-chair the WG. Thank you and welcome! Best Regards, Alexey, as ART AD From nobody Mon Mar 25 05:41:12 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70451203FD; Mon, 25 Mar 2019 05:41:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Barry Leiba , cbor@ietf.org, alexey.melnikov@isode.com, barryleiba@computer.org, cbor-chairs@ietf.org, draft-ietf-cbor-cddl@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155351766967.28964.6517259833650041915.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2019 05:41:09 -0700 Archived-At: Subject: [Cbor] Protocol Action: 'Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures' to Proposed Standard (draft-ietf-cbor-cddl-08.txt) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:41:10 -0000 The IESG has approved the following document: - 'Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures' (draft-ietf-cbor-cddl-08.txt) as Proposed Standard This document is the product of the Concise Binary Object Representation Maintenance and Extensions Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ Technical Summary 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 or JSON. Working Group Summary The CBOR working group has been working on the CDDL definition for about a year, and has had productive, healthy discussion that's led to the current document. There is quite wide deployment of CBOR and a lot of interesting in the definition language that's proposed here. As is typical, we had a core set of maybe half a dozen very active participants, with quite a few others chiming in occasionally. The document shepherd thinks the interest and contribution has been robust. There are no significant disagreements that remain, and there's solid working group consensus on what's here now. There have been disagreements about how to represent particular things, but they have been cleanly resolved and none are important to note here. I'll call out the latest one, as it's just come up: at the end of working group last call, Jim Schaad raised an issue on the mailing list about an ambiguity that affects automated parser generation. After discussion on the working group telechat, Carsten proposed text that clarifies that syntax alone may not always be sufficient to understand the meaning of a name, and that semantics of the name must be understood. Document Quality Multiple existing IETF documents are already using CDDL for specifying wire encodings. There are several implementations of CBOR parsers/generators. Personnel Barry Leiba is the document shepherd and Alexey Melnikov is the responsible AD. From nobody Mon Mar 25 07:29:36 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F361203D0 for ; Mon, 25 Mar 2019 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bij-pnbCsiDr for ; Mon, 25 Mar 2019 07:29:32 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70055.outbound.protection.outlook.com [40.107.7.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43A012038C for ; Mon, 25 Mar 2019 07:29:31 -0700 (PDT) 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=JvhHm2o0EEMc4BQOXbpW5tDmpjbbn7voN1dSWlJHHJw=; b=Ip9oKEs2cQNk/PF/q2YYHthi3nWdA7ty1nFdrOJvzgmudeEDeBr7Mnqc4F4hv69bobtmCW+4vrPTi2D81aQo6krt5rSKPD9hm1653zZ/Vm3YgUaS93gEmnbJEcibwa1miRDAmoAWQpIArCIt3sb6oRzsxHFCqUD+9QFPe+9KAYI= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2969.eurprd07.prod.outlook.com (10.168.95.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Mon, 25 Mar 2019 14:29:29 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2489:87b6:bfd8:727d%6]) with mapi id 15.20.1750.014; Mon, 25 Mar 2019 14:29:29 +0000 From: Francesca Palombini To: Alexey Melnikov , "cbor@ietf.org" CC: Jim Schaad , Barry Leiba Thread-Topic: [Cbor] CBOR co-chair change Thread-Index: AQHU4v0i1UpP9QxyUUGIS6BCqcE+AKYceRcA Date: Mon, 25 Mar 2019 14:29:29 +0000 Message-ID: <0F27549D-A2F7-4CDF-B9E9-37247BE9E291@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:1232:144:c59f:f863:eb13:7a40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0fb815b-40eb-4ffc-0d43-08d6b12e4a58 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2969; x-ms-traffictypediagnostic: HE1PR0701MB2969: x-ms-exchange-purlcount: 1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39860400002)(136003)(199004)(189003)(229853002)(6512007)(5660300002)(6116002)(25786009)(2906002)(6306002)(33656002)(53936002)(6246003)(71190400001)(36756003)(305945005)(4326008)(7736002)(478600001)(54906003)(46003)(44832011)(6436002)(71200400001)(81156014)(8676002)(8936002)(11346002)(99286004)(83716004)(966005)(476003)(2616005)(446003)(316002)(82746002)(14454004)(486006)(81166006)(76176011)(110136005)(4744005)(105586002)(2501003)(106356001)(6486002)(97736004)(186003)(6506007)(102836004)(68736007)(86362001)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2969; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ztfd26GCPjtUi2FdRsoInwL4xDbpJbiTu8UhaT9wNEwCbGp5Vxjh62sw0oVtF7Uhvgn/9Xl1rSZZEANXrSmDSqDDW8TwDFvqfw9bu26pON2C6bmFWt7y4JizDieQb+XPC0Gz1xj+b3qJt/YP3hhr+bSF11U9D8iuKZOhy4E9cb1VYdUYtaIjriinJT7j55VdEejoiciap3Be+qYZRArDV4MadYBP+mJKosQ+JMS9gszemZaIEv7mGAQDij5fOJK0OOoBh12J/6zfFZsB9yNONZ4tJHw6XBC6oi19znTtdKPg+b1AQ8oneGl26cCFjLBT5UwuMPdttECGwmBMjTMlg1sr98/cgQgkVRO+bCGfzwtPMO21V6V30VdzjpGiTYRk2Zsa8PH99hwP635tGiNwNsnlT0aSFu3awIVE2VJ1qVw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0fb815b-40eb-4ffc-0d43-08d6b12e4a58 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 14:29:29.1408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2969 Archived-At: Subject: Re: [Cbor] CBOR co-chair change X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:29:35 -0000 VGhhbmsgeW91IEJhcnJ5IGZvciB5b3VyIHdvcmssIGVzcGVjaWFsbHkgb24gc2hlcGhlcmRpbmcg YW5kIGhlbHBpbmcgbW92aW5nIENEREwgZm9yd2FyZCB0byBJRVNHISANCldlbGNvbWUgSmltLCB0 aGFuayB5b3UgZm9yIGFjY2VwdGluZyB0byBzZXJ2ZSwgSSBsb29rIGZvcndhcmQgdG8gd29ya2lu ZyB0b2dldGhlci4NCg0KRnJhbmNlc2NhDQoNCu+7v09uIDI1LzAzLzIwMTksIDEyOjIzLCAiQ0JP UiBvbiBiZWhhbGYgb2YgQWxleGV5IE1lbG5pa292IiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBhbGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tPiB3cm90ZToNCg0KICAgIERlYXIg Q0JPUiBwYXJ0aWNpcGFudHMsDQogICAgDQogICAgV2l0aCBCYXJyeSBMZWliYSBiZWluZyBzZWxl Y3RlZCBhcyBhbm90aGVyIEFSVCBBcmVhIERpcmVjdG9yIHRoaXMgV0cNCiAgICBuZWVkcyBhIG5l dyBjby1jaGFpciBmb3IgRnJhbmNlc2NhLiBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgQmFycnkgZm9y IGhpcw0KICAgIGNvbnRyaWJ1dGlvbnMhIEkgYW0gYWxzbyBwbGVhc2VkIHRvIGFubm91bmNlIHRo YXQgSmltIFNjaGFhZCBoYXMgYWdyZWVkDQogICAgdG8gY28tY2hhaXIgdGhlIFdHLiBUaGFuayB5 b3UgYW5kIHdlbGNvbWUhDQogICAgDQogICAgQmVzdCBSZWdhcmRzLA0KICAgIEFsZXhleSwgYXMg QVJUIEFEDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCiAgICANCg0K From nobody Mon Mar 25 07:51:25 2019 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1423B1204D3 for ; Mon, 25 Mar 2019 07:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155352548207.28984.9313988920841081248.idtracker@ietfa.amsl.com> Date: Mon, 25 Mar 2019 07:51:22 -0700 From: IETF Secretariat Archived-At: Subject: [Cbor] Milestones changed for cbor WG X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:51:23 -0000 Changed milestone "Submit CDDL to IESG as an Informational or Proposed Standard RFC", resolved as "Done". URL: https://datatracker.ietf.org/wg/cbor/about/ From nobody Mon Mar 25 08:15:48 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7241203EE for ; Mon, 25 Mar 2019 08:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyj4E0flkx45 for ; Mon, 25 Mar 2019 08:15:44 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 6A3DA1203C5 for ; Mon, 25 Mar 2019 08:15:44 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id b9so7887598iot.13 for ; Mon, 25 Mar 2019 08:15:44 -0700 (PDT) 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:content-transfer-encoding; bh=z0td9dUWGOdKdUslToLuxgj2gifbeWq4UYu2FIKZtP8=; b=hPzezrUK67FmpDO+BA3wfrrSWE4KVlsHDgU7UFQIBsN3cCtRQWgwYYM1+H/IHnkPX0 c5SKZ6VwwaOmDD4Fat4BThYHpB4nhbleHP5z4Ehs9uiFMaDTofz2hm6qFF2V/vsBqQj8 z1AJDOd8jpNI0dWMtt8jdJbpA5h0LTGQHkDWp12wN64Ypkl46hsK8QFyl8veBdsqYm8L BRS1HLaGvixW8z5w/VRoESYQb3ruE5QU2Jb7pHjgLR1vg7j4miWVJDGw4Z0Q7CxWPXNk 68tggv2Y5Zi/we8/UQKQ8vln9zjTBjxyQWtb3hQ33trI0dsCJfT6sZmA9fhR1zXNGQ97 tgwg== X-Gm-Message-State: APjAAAXKnFBTnRqeWkrqBVVLQaxNnKx2xKbyooZ/6Q3tIEZB7PZbXFHH y2o842+RooRlBonVqFV5MuFJ47NUHrKy3CTAlnc= X-Google-Smtp-Source: APXvYqy6Jw6KOFt4rBN93Yja9VGDESb1bNOUwoC1rGBGSrz0Vdn7aRYvborEx1R8CpRvnLi3PFjYHjILmrZAP/QpstA= X-Received: by 2002:a6b:3106:: with SMTP id j6mr18958729ioa.147.1553526943246; Mon, 25 Mar 2019 08:15:43 -0700 (PDT) MIME-Version: 1.0 References: <0F27549D-A2F7-4CDF-B9E9-37247BE9E291@ericsson.com> In-Reply-To: <0F27549D-A2F7-4CDF-B9E9-37247BE9E291@ericsson.com> From: Barry Leiba Date: Mon, 25 Mar 2019 16:15:51 +0100 Message-ID: To: Francesca Palombini , Jim Schaad Cc: "cbor@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] CBOR co-chair change X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 15:15:46 -0000 Thanks, guys; it was really a pleasure working with Francesca and y'all, and I'm sad to leave. But I'm looking forward to another couple of years in purgatory as an AD. Barry On Mon, Mar 25, 2019 at 3:29 PM Francesca Palombini wrote: > > Thank you Barry for your work, especially on shepherding and helping movi= ng CDDL forward to IESG! > Welcome Jim, thank you for accepting to serve, I look forward to working = together. > > Francesca > > =EF=BB=BFOn 25/03/2019, 12:23, "CBOR on behalf of Alexey Melnikov" wrote: > > Dear CBOR participants, > > With Barry Leiba being selected as another ART Area Director this WG > needs a new co-chair for Francesca. I would like to thank Barry for h= is > contributions! I am also pleased to announce that Jim Schaad has agre= ed > to co-chair the WG. Thank you and welcome! > > Best Regards, > Alexey, as ART AD > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > > From nobody Mon Mar 25 14:33:50 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71458120825 for ; Mon, 25 Mar 2019 14:33:49 -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 27Cm6HrRHv7k for ; Mon, 25 Mar 2019 14:33:47 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D8712035C for ; Mon, 25 Mar 2019 14:33:47 -0700 (PDT) Received: from client-0064.vpn.uni-bremen.de (client-0064.vpn.uni-bremen.de [134.102.107.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44SnZK3Yy9zyrM; Mon, 25 Mar 2019 22:33:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Mar 2019 22:33:45 +0100 Cc: Francesca Palombini , Jim Schaad , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 575242423.288335-0184379ad95970f685dc20bb9116cb3d Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F27549D-A2F7-4CDF-B9E9-37247BE9E291@ericsson.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] CBOR co-chair change X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 21:33:50 -0000 Hi Barry, we have to thank you much for enabling the success of CBOR in the first = place, and for the resounding success on the reverberation of which you = are now leaving: CDDL is approved! We are also looking forward to a great period with you as an ART = director. Gr=C3=BC=C3=9Fe, Carsten > On Mar 25, 2019, at 16:15, Barry Leiba = wrote: >=20 > Thanks, guys; it was really a pleasure working with Francesca and > y'all, and I'm sad to leave. But I'm looking forward to another > couple of years in purgatory as an AD. From nobody Fri Mar 29 04:07:56 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB95120264 for ; Fri, 29 Mar 2019 04:07:53 -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 ezqdf113DOuq for ; Fri, 29 Mar 2019 04:07:51 -0700 (PDT) Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.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 5AABA120258 for ; Fri, 29 Mar 2019 04:07:51 -0700 (PDT) Received: from dhcp-95db.meeting.ietf.org ([31.133.149.219]) by :SMTPAUTH: with ESMTPSA id 9pMShQROOtlFQ9pMTh0e8B; Fri, 29 Mar 2019 04:07:50 -0700 From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_10DDAC5F-0C23-494D-B100-AA9DDCA158DC" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <250C6053-B5B2-4A51-ACC7-3D156A8D17EF@island-resort.com> Date: Fri, 29 Mar 2019 12:07:47 +0100 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-CMAE-Envelope: MS4wfCHxoMAnJ8GZZJfudwVYkIoP1KLSlnpW5K8E6RLv6jLbJFS4/jv3vzJlDYqH1uivwzimPgFzQzeIzoq5X1Zwy70O08djo/tApXdhDTdSp+YV8MExx62i NLYxKSmRFmSo6fSVmjWBZCe6YWPOyJeOoYzAh6eIDWT0hvJSKNvF8vMOj5kRPedV1fPIFN/8debyvg== Archived-At: Subject: [Cbor] Another view on tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 11:07:54 -0000 --Apple-Mail=_10DDAC5F-0C23-494D-B100-AA9DDCA158DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seems like a large part of the value of defining tags is in the = selection or design of the type itself rather than the actual tagging. = It is the CBOR experts writing down the best way to encode some = particular type of data. Epoch-based date is a good example. If you want = to put a nice compact date into a CBOR protocol, use the epoch-based = date (and don=E2=80=99t do something awkward like repackage ASN.1 = GeneralizedTime). Bignums, decimal fractions, big floats and arrays are = types designed by CBOR experts. Epoch date, date string and the like are = existing types pre-approved for use in CBOR protocols by experts. Further, these standardized extended types, can be implemented by = generalized encoder/decoders and get broad support. This is a big win = IMO. It seems possible and sometimes useful to use these =E2=80=9Cextended = types=E2=80=9D without an explicit tag. A protocol might say, a = particular data item in a map should be in the format of a bigfloat even = though there is no tag 5. You might call this implicit tagging. I=E2=80=99m not sure where to go next: - Should we say explicitly that it is OK to use extended data types = without a tag? - Should general encoder decoders have APIs to deal with these extended = types even when not tagged?=20 - Recommendations for use of explicit or implicit tagging of extended = types in protocols?=20 LL --Apple-Mail=_10DDAC5F-0C23-494D-B100-AA9DDCA158DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Seems= like a large part of the value of defining tags is in the selection or = design of the type itself rather than the actual tagging.  It is = the CBOR experts writing down the best way to encode some particular = type of data. Epoch-based date is a good example. If you want to put a = nice compact date into a CBOR protocol, use the epoch-based date (and = don=E2=80=99t do something awkward like repackage ASN.1 GeneralizedTime). Bignums, decimal = fractions, big floats and arrays are types designed by CBOR = experts. Epoch date, date string and the like are existing types = pre-approved for use in CBOR protocols by experts.

Further, these standardized extended types, can be = implemented by generalized encoder/decoders and get broad support. This = is a big win IMO.

It seems possible and sometimes = useful to use these =E2=80=9Cextended types=E2=80=9D without an = explicit tag. A protocol might say, a particular data item in a map = should be in the format of a bigfloat even though there is no tag = 5. You might call this implicit tagging.

I=E2=80=99m not sure where to go = next:
- Should = we say explicitly that it is OK to use extended data types without a = tag?
- Should general encoder decoders have APIs to deal = with these extended types even when not tagged? 
- Recommendations = for use of explicit or implicit tagging of extended types in = protocols? 

LL




= --Apple-Mail=_10DDAC5F-0C23-494D-B100-AA9DDCA158DC-- From nobody Fri Mar 29 04:13:47 2019 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49112026A for ; Fri, 29 Mar 2019 04:13: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 1Jh6HNszKuxX for ; Fri, 29 Mar 2019 04:13:43 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDE4120268 for ; Fri, 29 Mar 2019 04:13:43 -0700 (PDT) Received: from dhcp-8804.meeting.ietf.org (dhcp-8804.meeting.ietf.org [31.133.136.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44Vzd13d87zyvc; Fri, 29 Mar 2019 12:13:41 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <250C6053-B5B2-4A51-ACC7-3D156A8D17EF@island-resort.com> Date: Fri, 29 Mar 2019 12:13:40 +0100 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 575550818.735672-ebb944704d203497896e8218efb85972 Content-Transfer-Encoding: quoted-printable Message-Id: <97D3468A-4265-41B8-BDAA-F3A4E14B9231@tzi.org> References: <250C6053-B5B2-4A51-ACC7-3D156A8D17EF@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cbor] Another view on tags X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 11:13:46 -0000 On Mar 29, 2019, at 12:07, Laurence Lundblade = wrote: >=20 > It seems possible and sometimes useful to use these =E2=80=9Cextended = types=E2=80=9D without an explicit tag. Yes. A somewhat informal way to make use of this in CDDL is: { Nbf: ~time Exp: ~time } (Where `time` is a `#6.1(number)` as per prelude.) Gr=C3=BC=C3=9Fe, Carsten