From nobody Thu Apr 5 03:00:53 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0217C126C25 for ; Thu, 5 Apr 2018 03:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=SbMFRdKh; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AZa6EYOI 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 5tBxuBcMWpW9 for ; Thu, 5 Apr 2018 03:00: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 931CB124205 for ; Thu, 5 Apr 2018 03:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522922440; 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=W//IMfpRUhTG8sfpHLNA/EDVg2w/7w9eVk/nOoIucqg=; b=SbMFRdKh+GSU9q4J4XQdp1s9mv+3guaX9IwGmh1salfxiQHUAQhN6JZxTKisCvuU OdQLBAltLPK3mrsYm0ZppDDbQAQ0U8gTjDo1CrRRjgWywPaZLLSJFArH3sVe4xlV LaHp6C9kCnXYF+Q45SbWejGfM3qrzWDVk/PhZVea3f8=; X-AuditID: c1b4fb2d-e31ff700000073d9-c8-5ac5f3c8f1d2 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.5B.29657.8C3F5CA5; Thu, 5 Apr 2018 12:00:40 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSHC012.ericsson.se (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 5 Apr 2018 12:00:40 +0200 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.1034.26; Thu, 5 Apr 2018 12:00:40 +0200 Received: from EUR03-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.1034.26 via Frontend Transport; Thu, 5 Apr 2018 12:00:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=awkuESqKdoBXRxi632Q4yV9xQRKx9dDKqJCHBOLpZ9Y=; b=AZa6EYOIWYOlVyCEd2ZT/BA9uWHpq+Gr1O2QvCfIeFUcuTAUBH9YRKV+l6NUVeQA6M6pNpS0o4RXTB5B07SQPvuCqQ+0DYKFCARLGNbWPdvd8SEV8NnWbDQfni6EZ9kTGeVcWTEhUG2pe083ZpVOFLeiFPNLDT5KvTWBS8BCR+E= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1418.eurprd07.prod.outlook.com (10.169.122.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.5; Thu, 5 Apr 2018 10:00:38 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::f0b7:7d19:1dac:a329]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::f0b7:7d19:1dac:a329%5]) with mapi id 15.20.0653.013; Thu, 5 Apr 2018 10:00:38 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes IETF101 CBOR Thread-Index: AdPMw3JQZymIl5htTEKWchmRN0e4gw== Date: Thu, 5 Apr 2018 10:00:38 +0000 Message-ID: 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.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1418; 7:5S75BYp4axW9XlK3Kh9UJDEAnmClc6VPl1PqoutDoiR5xM43GEu0rb5g5U7zdHBMgSMl4X+a6nPBgwxK07xiPAENecN008K0748p3woXJ2pLq/gvrI0HvMA/S7f8yYB3/ZQ0WWECwDElXQf0VNlxqDp2eEahQ2gu9pPOp5igeS6/LbsiUtof8zXiDiEqybaI6heR+XcmM3HHS9iEb67ufcZY1JTMy4Lyf8H1j4OAb1xO0dwc2/2NtfxAZQHdZsb0 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b30a430d-9507-46f8-2b2e-08d59adc1558 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB1418; x-ms-traffictypediagnostic: HE1PR07MB1418: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(268559375225159)(28532068793085)(120809045254105)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:HE1PR07MB1418; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1418; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(396003)(366004)(346002)(39860400002)(199004)(189003)(53754006)(486006)(66066001)(9686003)(26005)(8936002)(55016002)(3280700002)(561944003)(5660300001)(966005)(54896002)(33656002)(102836004)(3660700001)(2351001)(86362001)(6306002)(236005)(53946003)(6506007)(59450400001)(186003)(7696005)(5640700003)(478600001)(2906002)(106356001)(2900100001)(105586002)(7116003)(6116002)(53936002)(476003)(6436002)(99286004)(790700001)(68736007)(1730700003)(2501003)(74316002)(3846002)(606006)(14454004)(97736004)(8676002)(5630700001)(7736002)(6916009)(25786009)(4326008)(5250100002)(81156014)(19609705001)(450100002)(316002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1418; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vrzhdxmyaT1yrjVlDpIbrivT37Ld9A1eBJjVuyjAXS9eAwHuH1vllSECVtomL2UCeqwCdFK6jpW7BdXk22C81LHPAuXw6GDgDx9O7bjAlFGUIOLxwR9GM/maakfuW+RDqrionrzuTNw2/DnKHN+ReyI5CELuhrCGsWrFUikyPriVynCNLa8y8oBANwN/mbQr48oYwaH7vPfHTpXdwligsHeEZAsK7hJKIujp+JnfmbX2DfX5mWtIVrleidMpzCwXY/aq2rjl745fFrkoVfUyLfLW4b7Xrr45fUSGMHKRByg8H/8UYFivOoRh2hqMwt/z/VG0cDrW6WLERiQEbYOiHoXmybp50moKiTBG8W6UU+3LjjGGRSwPUdjIGzrzxD0Y+KUW0FtPB2RPTqu2eHf8RKT4tB1nUHpjhvURziQIFo0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB15297877A28554B6CEA06E1598BB0HE1PR07MB1529eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b30a430d-9507-46f8-2b2e-08d59adc1558 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 10:00:38.3544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1418 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUhTYRzGfc85OzvOBqel+NdSakmgsZUZJSFW3rQwyS4MWUEtPaip03am ZTawFDMlP8ChzgsTlolDSJ2kuMGcTU2wQhqW2ocpA5NQskmim+3sLOju9zzv8/+Cl8IlXYJI Kk+tZTRqVYGUFBFtma9OySY3HMrj1vrTie0eM0psq2khzmEKo3ELS0dKUVI2U5BXymiOJd8U 5TatjwmKDRb8ntnVh1eg2V2sFgVTQJ8Eh2ub5FhCv0ZgtSfUIpGPBxD0W9yIF5sIJgY9OC+M GLinXUJOEPQvDJy2uUCsCYOG3hEhLxYR7LytJrjOJJ0E7xfXBByH0odB3zzmm0hROB0PW5Y7 nL2PjgLTwo6Qj0ih/lNPgOUwsdLgZ4KOgS9V1X4W09fhaeekn5Gv9vdDE84xTofD3HJH4Dga jJZ3OM9hsLLkFfD5LPgwXy/kVgD6IBg9EXwkCmY66hDPZgwM7Rd5lsG6Xh9okwYjL9wkdyLQ kwjchtbArDiYHXpJ8pwPzrpNAc86cHr7EF/wHAerqysw4QDsWn+SjUhu+G9vnotg+FsVafDf uRfetC0TvC+Hj/pmkuej0NW5ivMsg1avnfjff4aEPSiMZVi2MOdEgpzR5GWxbJFarma0/cj3 e0bN27IhZFo9b0c0haR7xLHzDqVEoCplywrtCChcGioWVPoscbaq7D6jKbqhKSlgWDvaTxHS cLG8x6KU0DkqLZPPMMWM5t8rRgVHVqDu5FB2MfbSbjS1mWjLf+z8Ua7zmAYfdXcodF8TIjK/ LzBkTUpSTfmITRFTMpWRLU57Eq0fV4/GZNBNEemNd9noM5+vHpmR9Gqb10J6B86aHqSE3LrQ pFoKmtXNLzsM4zZK4b22GjJ9e+nyn9SFQy1BBu9UZOpa5ZahcPjKhkxKsLmq+Dhcw6r+Ak8N BvM5AwAA Archived-At: Subject: [Cbor] Minutes IETF101 CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 10:00:52 -0000 --_000_HE1PR07MB15297877A28554B6CEA06E1598BB0HE1PR07MB1529eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I uploaded the minutes for the CBOR meeting at IETF100 on the datatracker: = https://datatracker.ietf.org/doc/minutes-101-cbor/ Big thanks to Paul Hoffman and Christian Ams=FCss for taking them! Please let us know if you have any comment, and if you have actively partic= ipated, take a second to make sure that your comments were correctly captur= ed. I also want to join Alexey in thanking Joe for his time as chair, and welco= me Barry, looking forward to work together. Francesca -- CBOR IETF 101 - London Tuesday, Mar 20, 2018, 13:30-15:30 Chairs: Joe Hildebrand, Francesca Palombini Recordings: https://play.conf.meetecho.com/Playout/?session=3DIETF101-CBOR-= 20180320-1330 or https://youtu.be/FrVinVcs-P0 Minutes by Paul Hoffman, Christian Ams=FCss Nothing from the slides reproduced here * Introduction [15'] : Chairs https://youtu.be/FrVinVcs-P0?t=3D5m55s Agenda bashing and status update CDDL had WGLC, that generated review comments to be discussed today. 7049= bis: Implementation matrix updated (see wiki). array tags got reviews, read= y for adoption when reviews addressed. * CDDL, draft-ietf-cbor-cddl-02 Presented by Carsten Bormann https://youtu.be/FrVinVcs-P0?t=3D8m32s - Changes since IETF 100: cuts in maps introduced for one particular appl= ication. From regexp discussion there: Using XSD regexp that are still weir= d but not too much, and [something with unicode]. - Created a "freezer" document for things that will not go into the main = document - On map matching: CDDL has single concept of "groups" (for maps and arra= ys) that are grammars of types; describe linear languages. Linear propertie= s are only used for arrays, and as maps are unordered (thus match anything)= , implementations need to be driven from grammar and not from text. That al= so creates some nondeterminism -- that hasn't hurt anywhere, but edge cases= might come up. - Map validation (though "validation" not a term of CDDL): wildcard in ma= tches could consume explicit matches [if the scribe understood correctly]. = For that (and only that), cuts are introduced: once a fork is matched, the = path is committed, and if the rest won't match, the whole thing won't. This= is only meaningful on a match. That comes with limitations [...]. - Are there only editorial issues left, or is anything technical still op= en? Jeffrey Yasskin: Semantics of group and cuts are not specified well Wants to know precisely what causes a map to match. We need a precise s= pecification of the matching algorithm. Carsten: This is precise as it's a parse expression grammar, which is g= reedy. It becomes a problem when expressed in a nondeterministic[?] finite = automaton. Jim Schaad: Wants to change the ordering. Match the most specific keys first, specific before "any" Jeffrey: Can't say one type is more specific than other types. Choice types can just overlap and not be more specific than each other. Jim: Anything is a value > constructed type > groups (Value is more spe= cific than type is more specific than any.) Sean Leonard: I want to express that I am opposed to introducing "cuts" i= nto CDDL v1.0. Cuts transform a context-free grammar into a context-sensiti= ve one. An alternative, "subsets" or "constraints", was sketched out in Sin= gapore. From an editorial point, this is introducing new matter at the last= minute when it needs to be fleshed out more over the coming months, i.e., = after we get this version of CDDL out. (So basically it is similar to Jeffr= ey Yaskin's point: not well specified and also trying to do too much.) Carsten: If we want colon to be a short cut for "^ =3D>", we need to do= this now, can't be added later. And that is the meaning probably most spec= writers will expect of ":". The alternative is to smearing the previous ca= ses into the later more generic ones. This won't make concise specificatons= . Jeffrey: useful to have ":"" syntax act as a cut, not sure we need th= e cut syntax. Just column is maybe easier to specify. Henk Birkholz: Exception is the behavior of cuts If we don't want a simple notation, we need to decide this soon Likes the last example; intuitive Carsten: The interesting proposal here is to only have ":" and not "^". It's weird to have a shortcut that you can't have in long form Sean: (refers to slide 15) So the point is that you want to say "4 is t= ext only, all other uints are anything else", right? So the slide says "* u= nit" and that means "* all uints except 4", right? What happens when later = you want to say 5 is only a byte string? You have to put ? 5 : at the top, = but you can't put it at the top, you are supposed to be putting it at the b= ottom... Jim: if you append a colon-thing to the bottom, you're going to expect = enforcement, but not checked/enforced. Carsten: By creating a sorting mechanism, this consideration could be h= andled. I don't like the sorting mechanism b/c spec writer can intend a seq= uence. Sean/Jim: Spec writer can intend a sequence, but extension writer can o= nly append. Carsten: [...] You can give the first thing a name, and have that as an= extension point, and have the wild card after the named. Sean: The way that "constraints" work is that you say, with appropriate= syntax: * unit -> any FIRST. Then in the subsequent parts of the spec, you= identify specific instances of *uint =3D> any. For example: "when uint is = 4: text". "When uint is 5: byte string". (this is discussed in draft-seante= k-constrained-abnf, for ABNF.) Carsten: [...] There are several proposals. Some proposal to have the s= hortcut but not the long form, others not to do that at all (refer to slide= 15). Take it from the list from there. Francesca: Yes. - Carsten: Next topic: operator precedence. Operator precedence is logica= l when it comes to groups and types. The same syntax in a map context is un= familiar in a type choice after a [quantifier]. General changes in operator= precedence would create annoyance in form of needing more parens and raisi= ng syntax errors if missing. We can add text to explain and encourage a sty= le that doesn't contain surprising cases. Comments? Room: silent. Hank: I see the necessity, but it violates the rule of not being noisy,= and specs will be paren-laden after that, and move away from the being eas= y-to-read-and-write, but I see the point. Paul: It's never too hard to read too many parenthesis. Carsten: It doesn't need to be names, more common is to name the choice= and than use that name. We can still make the recommendation w/o littering= up specs -- but yes, we should check that. Carsten: Addressing Jim's review. @Dead code: should not lead to hard errors. A tool might still give war= nings on that. It's generally undecidable, but often possible in realistic = cases. @generics: grammar says it, text doesn't, but should say it too. @prece= dence: there were errors. @unwrap grammar: found copy/paste error. @terminology: we should make it visible that there are CBOR and CDDL te= rms, and they never mix. Jeffrey: CDDL spec is written as a tutorial, not a spec Appendix C is a good start, but it should move there before becoming an= RFC. Carsten: A sensible proposition -- which would need half a year. Jeffrey: can we speed that up with a pull-request style? Alexey: Is this just reordering? Jeffrey: More. For some cases, I don't even know the algorithm Carste= n has in mind. For other, it's clear enough that I'd be capable of writing = the spec, but it takes time. I could sketch something in a month, but getting the exact words woul= d take longer. Francesca: The WG said it wants this out as soon as possible Sean: Let's get version 1 out now and run a more formal spec on next ve= rsion if we feel it's necessary. Jim: Agrees Joe Hildebrand: Sees a ton a value for this, but wants something sooner Carsten: Wants a list of the items Jeffrey does not understand Jeffrey: Can't currently use this in web specs Joe: We know that there is still work to do, we expect a -bis Alexey: Is comfortable with this approach Alexey: When can you be done? Carsten: Before late May. Would like to get input from Jeffrey. Francesca: To the WG: keep checking the doc (see github for most recent u= pdate). Bring leftover points/issues to the mailing list. After the update,= we'll see if we need another WGLC. * CBOR specification, draft-ietf-cbor-7049bis-02 Presented by Carsten Borma= nn https://youtu.be/FrVinVcs-P0?t=3D51m52s - This is about taking this to standard level, learn from first 5 years b= ut don't futz around. This is way beyond errata, but follows the definition= of standard level (look it up). - Since -00: experience says making readers infer data model from spec is= mistake. We now define "generic data model" with extension points. - Separation of integer and floating point types (as it has been used). T= hat played back into key equivalence. Now there are environments that don't= allow that separation easily -- and we can't fix that. Needs to be conside= red when writing a model, will need a bit of general guidance. Joe: In JSON RFC, if you use something like an integer that is >2^53, you= 'll have problems Carsten: We won't have that problem Joe: Nevermind, not an useful idea - On canonicalization (c14n): this was problematic btwn authors in origin= al spec, but there are uses for it -- let's help those people. Careful: The= re is key equivalence that can come from the application level. Floats are = problematic too. We want to encourage generic encoder writers to not ignore= it when users ask for c14n. To help them: Provide recommendations (and tha= t's all that is in the RFC). Those recommendation rules were leaky, and key= order (often complained about by implementors). The key order will change t= o byte-wise lexical -- but we also keep the old one in (but not recommendat= ion) so existing specs can still reference it. Too bad, sorry. We will want= to be more specific in float normalization; we have 3 models, should we ex= press a preference? Own preference: Prefer shortest encoding in all cases (= For int, length info, strings, tag number, floating, bignum etc). Jim: Worries about things like bignums into ints Worries about loss of tagging Carsten agrees, but has questions about whether it matters Jim: Yes in the crypto world completely different things Paul: For example a counter that is supposed to be 128bits Carsten: You can represent that in 64 bits if you can Jim: TSA signature, 2 int. Jeffrey: 2 examples. From FIDO: AGL found software bugs based on proces= sors getting the length wrong. Geo location extansion to web authen that us= e floating point, did not want short encoding for floating. Matt Miller: More in the cryptographic context, if uses as a counter, s= emantic of a counter but syntax a set of bits of determinate length. Catast= rophic to decrypt. Proposal: if we propose shortest encoding you have to ha= ve very clear considerations that you have to be careful Carsten: Example of things that need to be constant size Joe: We have the option of saying "don't do canonicalization of any pro= tocol, use bytes" Carsten: We can do both. In the crypto space, we have learned it is b= ad, but in other use spaces, it could be OK Thiago Macieira: What happens if you decode and reincode in a compliant= program You may be making bignums in all implementations Does this mean that bignums become mandatory? Carsten: It might be an option for your decoder Another thing a decoder can do is *check* canonicalization. Does this answer the question? Thiago: It's an answer to the question, but I am not satisfied. Matt: An alternative nuclear option: point to a different document Sean: A separate document might be good Jeffrey: All the specs should specify canonical output for testing Also contrains encoders to what they can put out We don't have to state a preference, but for basic generic data model= we can have one but not extended generic, and giving such a canonicalizati= on a name is sufficient for other specs. Sean: To what extent is type and tag is assumed to be saved across enco= ding Jim: +1. Are you canonicalizing the data model or the CBOR structure Carsten: Yes It's important for parser speed that it can discard information tha= t is immaterial to the data model. Whether that includes int/bignum is up t= o questio Joe: If something is in canonical form, and I re-generate canonical for= m, these are equal. Carsten: That's almost the definition of canonical. Paul: Suggests that we only list ideas, but no preferences We should give some information, "but you make your own rules, and yo= u're gonna cry." Jeffrey: Generic canonical is bad thing, protocol specific canonicaliza= tiion is important Matt: CBOR has as strong idea of what types are, unlike JSON. 1 more vo= te to do not deal with canon in this doc Joe: A world with 20 CBOR canonicalizations would be much worse than wh= ere we are today ASN.1 are an anti-pattern for writing a parser 1) Never canonicalize, it's evil 2) Here is a canonicalization form in this doc 3) There is a canonicalization form in another doc Sean: I guess the point is, to what extent is CBOR type & tag informati= on supposed to be preserved when serializing between different implementati= ons? Carsten: We can split the technical issues from the procedural issues. Jeffrey: The rest of the set is close to ready, but this is not, sugges= ts different doc Alexey: Group needs to decide between "saying very little" and "strongl= y against it" Paul: For this doc we can say "it got took out for a reason". There mig= ht be a doc in the future Carsten: Splitting out might be the best way. Thiago: Also yank of equivalence of keys Joe: Good point, we need to do analysis first - implementation matrix Jeffrey: There should be a better way to determine consensus to accept PR= submitted to github Pull requests should be discussed on the list sooner Francesca: Reminder: important/big PR should go to the list Joe: we can be more aggressive on getting them included when we think t= he consensus has been reached Paul: Maybe wait three weeks after the end of discussion in the mailing list to include them Jeffrey: Chrome has two implementations that will get added * Array Tag, draft-jroatch-cbor-tags-07, Presented by Carsten Bormann https://youtu.be/FrVinVcs-P0?t=3D1h35m56s 2-byte space or 3-byte space Paul: 2-byte is fine Jim: 3-byte is fine and we might end up regretting Sean: Weak +1 for 3-byte Other registration in IANA overlaps Alexey: We cannot stop them but maybe we can convince them Zach Shelby: Did something in CORE Also has a fast track Maybe have a separation of rules Will be adopted in the WG * Wrap-up: Chairs https://youtu.be/FrVinVcs-P0?t=3D1h53m38s Joe: will be stepping down as CBOR chair --_000_HE1PR07MB15297877A28554B6CEA06E1598BB0HE1PR07MB1529eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

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

Big thanks to Paul Hoffman and Christian Ams=FCss fo= r taking them!

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

 

I also want to join Alexey in thanking Joe for his t= ime as chair, and welcome Barry, looking forward to work together.

 

Francesca

 

--

CBOR

IETF 101 - London

Tuesday, Mar 20, 2018, 13:30-15:30<= /span>

Chairs: Joe Hildebrand, Francesca Palombini

Recordings: https://play.conf.meetecho.com/Pla= yout/?session=3DIETF101-CBOR-20180320-1330 or https://youtu.be/FrVinVcs-P0<= o:p>

  Minutes by Paul Hoffman, Christian Ams= =FCss

  Nothing from the slides reproduced here=

 

* Introduction [15'] : Chairs

  https://youtu.be/FrVinVcs-P0?t=3D5m55s<= o:p>

  Agenda bashing and status update

  CDDL had WGLC, that generated review co= mments to be discussed today. 7049bis: Implementation matrix updated (see w= iki). array tags got reviews, ready for adoption when reviews addressed.

 

 

* CDDL, draft-ietf-cbor-cddl-02 Presented by C= arsten Bormann

   https://youtu.be/FrVinVcs-P0?t=3D= 8m32s

  - Changes since IETF 100: cuts in maps = introduced for one particular application. From regexp discussion there: Us= ing XSD regexp that are still weird but not too much, and [something with unicode].

  - Created a "freezer" documen= t for things that will not go into the main document

  - On map matching: CDDL has single conc= ept of "groups" (for maps and arrays) that are grammars of types;= describe linear languages. Linear properties are only used for arrays, and as maps are unordered (thus match anything), implementations n= eed to be driven from grammar and not from text. That also creates some non= determinism -- that hasn't hurt anywhere, but edge cases might come up.

  - Map validation (though "validati= on" not a term of CDDL): wildcard in matches could consume explicit ma= tches [if the scribe understood correctly]. For that (and only that), cuts are introduced: once a fork is matched, the path is committed,= and if the rest won't match, the whole thing won't. This is only meaningfu= l on a match. That comes with limitations [...].

  - Are there only editorial issues left,= or is anything technical still open?

  Jeffrey Yasskin: Semantics of group and= cuts are not specified well

    Wants to know precisely wha= t causes a map to match. We need a precise specification of the matching al= gorithm.

    Carsten: This is precise as= it's a parse expression grammar, which is greedy. It becomes a problem whe= n expressed in a nondeterministic[?] finite automaton.

  Jim Schaad: Wants to change the orderin= g.

    Match the most specific key= s first, specific before "any"

    Jeffrey: Can't say one type= is more specific than other types.

    Choice types can just overl= ap and not be more specific than each other.

    Jim: Anything is a value &g= t; constructed type > groups (Value is more specific than type is more s= pecific than any.)

  Sean Leonard: I want to express that I = am opposed to introducing "cuts" into CDDL v1.0. Cuts transform a= context-free grammar into a context-sensitive one. An alternative, "subsets" or "constraints", was sketched out in Singap= ore. From an editorial point, this is introducing new matter at the last mi= nute when it needs to be fleshed out more over the coming months, i.e., aft= er we get this version of CDDL out. (So basically it is similar to Jeffrey Yaskin's point: not well specified and also trying t= o do too much.)

    Carsten: If we want colon t= o be a short cut for "^ =3D>", we need to do this now, can't b= e added later. And that is the meaning probably most spec writers will expe= ct of ":". The alternative is to smearing the previous cases into t= he later more generic ones. This won't make concise specificatons.

      Jeffrey: useful= to have ":"" syntax act as a cut, not sure we need the cut = syntax. Just column is maybe easier to specify.

    Henk Birkholz: Exception is= the behavior of cuts

      If we don't wan= t a simple notation, we need to decide this soon

      Likes the last = example; intuitive

    Carsten: The interesting pr= oposal here is to only have ":" and not "^".=

      It's weird to h= ave a shortcut that you can't have in long form

    Sean: (refers to slide 15) = So the point is that you want to say "4 is text only, all other uints = are anything else", right? So the slide says "* unit" and th= at means "* all uints except 4", right? What happens when later you want = to say 5 is only a byte string? You have to put ? 5 : at the top, but you c= an't put it at the top, you are supposed to be putting it at the bottom...<= o:p>

    Jim: if you append a colon-= thing to the bottom, you're going to expect enforcement, but not checked/en= forced.

    Carsten: By creating a sort= ing mechanism, this consideration could be handled. I don't like the sortin= g mechanism b/c spec writer can intend a sequence.

    Sean/Jim: Spec writer can i= ntend a sequence, but extension writer can only append.

    Carsten: [...] You can give= the first thing a name, and have that as an extension point, and have the = wild card after the named.

    Sean: The way that "co= nstraints" work is that you say, with appropriate syntax: * unit ->= any FIRST. Then in the subsequent parts of the spec, you identify specific instances of *uint =3D> any. For example: "when uint is 4: text&qu= ot;. "When uint is 5: byte string". (this is discussed in draft-s= eantek-constrained-abnf, for ABNF.)

    Carsten: [...] There are se= veral proposals. Some proposal to have the shortcut but not the long form, = others not to do that at all (refer to slide 15). Take it from the list from there.

    Francesca: Yes.<= /span>

  - Carsten: Next topic: operator precede= nce. Operator precedence is logical when it comes to groups and types. The = same syntax in a map context is unfamiliar in a type choice after a [quantifier]. General changes in operator precedence would = create annoyance in form of needing more parens and raising syntax errors i= f missing. We can add text to explain and encourage a style that doesn't co= ntain surprising cases. Comments? Room: silent.

    Hank: I see the necess= ity, but it violates the rule of not being noisy, and specs will be paren-l= aden after that, and move away from the being easy-to-read-and-write, but I see the point.

    Paul: It's never too h= ard to read too many parenthesis.

    Carsten: It doesn't ne= ed to be names, more common is to name the choice and than use that name. W= e can still make the recommendation w/o littering up specs -- but yes, we should check that.

  Carsten: Addressing Jim's review.<= /o:p>

    @Dead code: should not lead= to hard errors. A tool might still give warnings on that. It's generally u= ndecidable, but often possible in realistic cases.

    @generics: grammar say= s it, text doesn't, but should say it too. @precedence: there were errors.<= o:p>

    @unwrap grammar: found copy= /paste error.

    @terminology: we should mak= e it visible that there are CBOR and CDDL terms, and they never mix.

  Jeffrey: CDDL spec is written as a tuto= rial, not a spec

    Appendix C is a good start,= but it should move there before becoming an RFC.

    Carsten: A sensible proposi= tion -- which would need half a year.

      Jeffrey: can we= speed that up with a pull-request style?

    Alexey: Is this just reorde= ring?

      Jeffrey: More. = For some cases, I don't even know the algorithm Carsten has in mind. For ot= her, it's clear enough that I'd be capable of writing the spec, but it takes time.

      I could sketch = something in a month, but getting the exact words would take longer.

    Francesca: The WG said it w= ants this out as soon as possible

    Sean: Let's get version 1 o= ut now and run a more formal spec on next version if we feel it's necessary= .

      Jim: Agrees

    Joe Hildebrand: Sees a ton = a value for this, but wants something sooner

    Carsten: Wants a list of th= e items Jeffrey does not understand

    Jeffrey: Can't currently us= e this in web specs

    Joe: We know that there is = still work to do, we expect a -bis

    Alexey: Is comfortable with= this approach

  Alexey: When can you be done?

    Carsten: Before late May. W= ould like to get input from Jeffrey.

  Francesca: To the WG: keep checking the= doc (see github for most recent update). Bring leftover points/issues to t= he mailing list. After the update, we'll see if we need another WGLC.

 

* CBOR specification, draft-ietf-cbor-7049bis-= 02 Presented by Carsten Bormann

  https://youtu.be/FrVinVcs-P0?t=3D51m52s=

  - This is about taking this to standard= level, learn from first 5 years but don't futz around. This is way beyond = errata, but follows the definition of standard level (look it up).

  - Since -00: experience says making rea= ders infer data model from spec is mistake. We now define "generic dat= a model" with extension points.

  - Separation of integer and floating po= int types (as it has been used). That played back into key equivalence. Now= there are environments that don't allow that separation easily -- and we can't fix that. Needs to be considered when writing a mod= el, will need a bit of general guidance.

  Joe: In JSON RFC, if you use something = like an integer that is >2^53, you'll have problems

    Carsten: We won't have that= problem

    Joe: Nevermind, not an usef= ul idea

  - On canonicalization (c14n): this was = problematic btwn authors in original spec, but there are uses for it -- let= 's help those people. Careful: There is key equivalence that can come from the application level. Floats are problematic too. We w= ant to encourage generic encoder writers to not ignore it when users ask fo= r c14n. To help them: Provide recommendations (and that's all that is in th= e RFC). Those recommendation rules were leaky, and keyorder (often complained about by implementors). The key= order will change to byte-wise lexical -- but we also keep the old one in = (but not recommendation) so existing specs can still reference it. Too bad,= sorry. We will want to be more specific in float normalization; we have 3 models, should we express a pre= ference? Own preference: Prefer shortest encoding in all cases (For int, le= ngth info, strings, tag number, floating, bignum etc).

    Jim: Worries about things l= ike bignums into ints

      Worries about l= oss of tagging

    Carsten agrees, but has que= stions about whether it matters

    Jim: Yes in the crypto worl= d completely different things

    Paul: For example a counter= that is supposed to be 128bits

    Carsten: You can represent = that in 64 bits if you can

    Jim: TSA signature, 2 int.<= o:p>

    Jeffrey: 2 examples. From F= IDO: AGL found software bugs based on processors getting the length wrong. = Geo location extansion to web authen that use floating point, did not want short encoding for floating.

    Matt Miller: More in the cr= yptographic context, if uses as a counter, semantic of a counter but syntax= a set of bits of determinate length. Catastrophic to decrypt. Proposal: if we propose shortest encoding you have to have very clear cons= iderations that you have to be careful

      Carsten: Exampl= e of things that need to be constant size

    Joe: We have the option of = saying "don't do canonicalization of any protocol, use bytes"

      Carsten: We can= do both. In the crypto space, we have learned it is bad, but in other use = spaces, it could be OK

    Thiago Macieira: What happe= ns if you decode and reincode in a compliant program

      You may be maki= ng bignums in all implementations

      Does this mean = that bignums become mandatory?

      Carsten: It mig= ht be an option for your decoder

        Ano= ther thing a decoder can do is *check* canonicalization.<= /p>

        Doe= s this answer the question?

      Thiago: It's an= answer to the question, but I am not satisfied.

    Matt: An alternative nuclea= r option: point to a different document

      Sean: A separat= e document might be good

    Jeffrey: All the specs shou= ld specify canonical output for testing

      Also contrains = encoders to what they can put out

      We don't have t= o state a preference, but for basic generic data model we can have one but = not extended generic, and giving such a canonicalization a name is sufficie= nt for other specs.

    Sean: To what extent is typ= e and tag is assumed to be saved across encoding

      Jim: +1. Ar= e you canonicalizing the data model or the CBOR structure=

      Carsten: Yes

        It'= s important for parser speed that it can discard information that is immate= rial to the data model. Whether that includes int/bignum is up to questio

    Joe: If something is in can= onical form, and I re-generate canonical form, these are equal.<= /span>

      Carsten: That's= almost the definition of canonical.

    Paul: Suggests that we only= list ideas, but no preferences

      We should give = some information, "but you make your own rules, and you're gonna cry.&= quot;

    Jeffrey: Generic canonical = is bad thing, protocol specific canonicalizatiion is important

    Matt: CBOR has as strong id= ea of what types are, unlike JSON. 1 more vote to do not deal with canon in= this doc

    Joe: A world with 20 CBOR c= anonicalizations would be much worse than where we are today

      ASN.1 are an an= ti-pattern for writing a parser

      1) Never canoni= calize, it's evil

      2) Here is a ca= nonicalization form in this doc

      3) There is a c= anonicalization form in another doc

    Sean: I guess the point is,= to what extent is CBOR type & tag information supposed to be preserved= when serializing between different implementations?

    Carsten: We can split the t= echnical issues from the procedural issues.

    Jeffrey: The rest of the se= t is close to ready, but this is not, suggests different doc

    Alexey: Group needs to deci= de between "saying very little" and "strongly against it&quo= t;

    Paul: For this doc we can s= ay "it got took out for a reason". There might be a doc in the fu= ture

    Carsten: Splitting out migh= t be the best way.

    Thiago: Also yank of e= quivalence of keys

      Joe: Good point= , we need to do analysis first

  - implementation matrix

  Jeffrey: There should be a better way t= o determine consensus to accept PR submitted to github

    Pull requests should be dis= cussed on the list sooner

    Francesca: Reminder: import= ant/big PR should go to the list

    Joe: we can be more aggress= ive on getting them included when we think the consensus has been reached

    Paul: Maybe wait three week= s after the end of discussion in

     the mailing list to i= nclude them

  Jeffrey: Chrome has two implementations= that will get added

 

* Array Tag, draft-jroatch-cbor-tags-07, Prese= nted by Carsten Bormann

  https://youtu.be/FrVinVcs-P0?t=3D1h35m5= 6s

  2-byte space or 3-byte space=

    Paul: 2-byte is fine

    Jim: 3-byte is fine and we = might end up regretting

    Sean: Weak +1 for = 3-byte

  Other registration in IANA overlaps

    Alexey: We cannot stop them= but maybe we can convince them

    Zach Shelby: Did something = in CORE

      Also has a fast= track

      Maybe have a se= paration of rules

  Will be adopted in the WG

 

* Wrap-up: Chairs

  https://youtu.be/FrVinVcs-P0?t=3D1h53m3= 8s

  Joe: will be stepping down as CBOR chai= r

 

--_000_HE1PR07MB15297877A28554B6CEA06E1598BB0HE1PR07MB1529eurp_-- From nobody Thu Apr 5 09:21:51 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA58912DA3D for ; Thu, 5 Apr 2018 09:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11oQsdK0a80a for ; Thu, 5 Apr 2018 09:21:46 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 8F87112DA23 for ; Thu, 5 Apr 2018 09:21:46 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 142-v6so3409367itl.5 for ; Thu, 05 Apr 2018 09:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/W9r4Fo6oWCevTOFqj7YeXuW7AHyY/k8Xe3wRSpfcFE=; b=G2+3LsChQ+bWQpLnxS3z/8MkISjuBJK+DgCSxdZ6pd2tp8yaQzG+3GVnkqLjrTM31a MD9vwccSutUrkZdHsi/ZFzhF3JASfJiapeRU6qOvo3Nz16G+FHf0UEBWCyjvfaBXeFMh vX4/73bfRaSJ8X7U5qPyJsWvQLpJAFh1z7ynlMOWV4qx4JD9pmI3BZ18TjFf4PUNIQrN 4RzUzo+pmAy/SpECWBt30E6cvbNgA67NJMjLQwwDc+tUDZ4sCuMNPoLfHuynLddgdbdd 7XGPZ1mXkeUBY8Iol7GHaWuNxtYHCHY+EoboB5q6noAwYelaeFnj9+ag0G5y/2Psp6yY Sw8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/W9r4Fo6oWCevTOFqj7YeXuW7AHyY/k8Xe3wRSpfcFE=; b=C0LUIE5ryIpXfFSX0I1uk/WgkxrDmE1Cw7ANuP0v6USJBurq1P168UX9iBzrQ/ECT9 k+2Bx1x6F630sS7Re8tpM1ZNPoTzu4+g2uNm6pfZrRY3yX0SXcDUJE+nxSFobifg9guI 4XC48MnNCz2HMGgWZANqqV937QbegA+WulREwg/JXtU23d4u974sD1gNP12jkJErB3oW OvpHmTlFvng3P/Jf8vTsCTcDUT5klsoZfBazRCi06z8th69xcrS2+oFTuGkB/ZVUWHMV ris/erVd0DDlmhTRSEMmCVwUDlaULyewNtc3B8WvxOT6kDGAwDleOkNuzv8sYa2m9tEU t1Nw== X-Gm-Message-State: ALQs6tCsfhX0x2sTPYgY3btunu9dDQrnNN2FLUFHleGvbKGv8ECo1MWF 9JHRf17Jdtne0SCyjkwTIj4DJ/3NmPHs2Yhpwp5vik5RPyY= X-Google-Smtp-Source: AIpwx49Nsv2LzDPaX837PtJMHTtZIwCMorPYGCx7hPpJsePFB1wNau9WyyVLhTDOo2EBY6OpcIzMGYr+bgKvGdPjlXI= X-Received: by 2002:a24:8183:: with SMTP id q125-v6mr15020321itd.106.1522945305151; Thu, 05 Apr 2018 09:21:45 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Thu, 05 Apr 2018 16:21:32 +0000 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000eddfbd05691c5526" Archived-At: Subject: [Cbor] 3 small CBOR changes X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:21:49 -0000 --000000000000eddfbd05691c5526 Content-Type: text/plain; charset="UTF-8" https://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data Models section. https://github.com/cbor-wg/CBORbis/pull/19 fixes an example of Javascript being unable to distinguish strings from numbers when they're used as map keys, since the Map type can in fact distinguish those. The new example uses the integer 1 vs the floating point value 1.0, but even that will be wrong once https://github.com/tc39/proposal-bigint makes it in, when typeof(some_int) could be "bigint" in a CBOR library that so chose. https://github.com/cbor-wg/CBORbis/pull/20/files changes a statement that depending on map order "would be very bad practice" in protocols using CBOR to a statement that these protocols "MUST NOT" do that. Thoughts? Note that we discussed at IETF101 a policy that the editors can merge a change 3 weeks after the last list discussion, on the theory that if anyone objects, they'll say so by then. Jeffrey --000000000000eddfbd05691c5526 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data Mode= ls section.

https://github.com/cbor-wg/CBORbis/pull/19 fixes an exam= ple of Javascript being unable to distinguish strings from numbers when the= y're used as map keys, since the Map type can in fact distinguish those= . The new example uses the integer 1 vs the floating point value 1.0, but e= ven that will be wrong once https://github.com/tc39/proposal-bigint=C2=A0makes it in, when typ= eof(some_int) could be "bigint" in a CBOR library that so chose.<= br>

https://github.com/cbor-wg/CBORbis/pull/20/files changes= a statement that depending on map order "would be very bad practice&q= uot; in protocols using CBOR to a statement that these protocols "MUST= NOT" do that.

Thoughts?

Note that we discussed at IETF101 a policy that the editors can me= rge a change 3 weeks after the last list discussion, on the theory that if = anyone objects, they'll say so by then.

Jeffre= y
--000000000000eddfbd05691c5526-- From nobody Thu Apr 5 09:22:30 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C145A12DA3D for ; Thu, 5 Apr 2018 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Guzc_dCA-BI for ; Thu, 5 Apr 2018 09:22:27 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 E839B12DA23 for ; Thu, 5 Apr 2018 09:22:26 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id b20so31302243iof.5 for ; Thu, 05 Apr 2018 09:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LiNGN6l2k2w2vsPdMy7T1UscNzX9NZXQzHTav0+r1Q0=; b=dT+Z07+3QM1oI7eaDlfEmFSxddW5eBiOK6ud6Vb4Q+SRaUp5dnTSKfaNDX5HfUpffr ILSNKvbgzsvxLoQFpNdMscgQRrJNiKlqIhIklcL0E6PwmvltVZU9NmH5g/7I+TiitnU+ Ga+Kp1nAuPugxwl4A/9MWgGfoqiG0RhyDMVKFwowBNSdiEA+HIMI70fxXD8bTECxAUDj GVi1yfmF7YqTJf1RxE1l9WkfYt5GjZ0V4ulTJGPQFR11qWRXLZr+ljkxy7Fd4md+6q2A AuaCRgSiKb17JaT9+cCJbrr9ZB22iebwQyoRX03Bbz0QBWcXjdKMYrccwzqbEsr/4Er/ sl4w== 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; bh=LiNGN6l2k2w2vsPdMy7T1UscNzX9NZXQzHTav0+r1Q0=; b=o8acL53Yy+L5P4uT8r7eKJbQKLLk60mhmzZWMKV7HgfJN1gZ3DDRu7ETnfwOpDEnao KvUjUp7YszsG0d+p/OiAHbKT01EA7TuZEcjT6qhjWR/aAokkdiMOzkpUWIiDbKWol21T Ds2zsm9Hvc7oqkHAzgsz6DSxXTM8954p9iTFDiDI9Vuju2R2ePCYhmoVW0aGlirN+N4A MuyhM8cv6y+/fwpYuf7s9sRPNvw8J62G8XLhRcxUTLtEMB1wJk4p2fMaoL2BrJfVhjdZ tSXtJfC3fXdS8eFDpkOId9DscDNTMXTjoMsMQRsAQQ+TN9YhgcfVVSkpv6BJgQmd3WK6 8S8Q== X-Gm-Message-State: ALQs6tD/ZT2xNcBpOUCyHtFCKo3vtvB84b+AEpGcHu1vMONaZ/RIY+fD vt4LGpAZf+5kldabRSWtMy3p1XWkfh3IoGp+3hgJ6Tow X-Google-Smtp-Source: AIpwx4+fCY5c5yfCclP2hc0NnxeyddNQtp2+o4+6PJzmK55qB0BHOMDmBeb3yMGYSloL9M5JkQvkMJS3THPeZlf1zrc= X-Received: by 10.107.181.141 with SMTP id e135mr20344160iof.189.1522945345661; Thu, 05 Apr 2018 09:22:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 05 Apr 2018 16:22:15 +0000 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a114449ce57d10005691c5872" Archived-At: Subject: Re: [Cbor] Making CBOR parsing more rigorous X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:22:29 -0000 --001a114449ce57d10005691c5872 Content-Type: text/plain; charset="UTF-8" Does anyone have opinions about these changes? On Fri, Mar 23, 2018 at 10:04 AM Jeffrey Yasskin wrote: > I have a collection of PRs against CBORbis to try to make parsing more > rigorous, to deal with objections from web spec owners like > https://github.com/mozilla/standards-positions/issues/29#issuecomment-334376573. > I haven't yet run these changes by a web spec person to make sure they're > complete, so there might be another set of PRs coming after these are in. > > https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define > which kinds of CBOR parsers need to detect which errors in the encoded > data, and which errors are recoverable. > > The basic idea is to classify encoded CBOR data into valid, > invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed > categories, and then use that in this and derived specifications to > describe parser behavior precisely. > > A question came up whether we can give an item's "unsigned integer" a > better name. Any ideas? > > https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds > of tagged items are valid. > > Let me know what you think. Approving PRs is probably helpful to the > editors even if you have no comments. > > Thanks, > Jeffrey > > --001a114449ce57d10005691c5872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does anyone have opinions about these changes?

On Fri, Mar 23, 2018 at 10:04 AM = Jeffrey Yasskin <jyasskin@google.= com> wrote:
I have a collection of PRs against CBORbis to try to make parsing more rig= orous, to deal with objections from web spec owners like=C2=A0https://github.com/mozilla/standards-positions/issues= /29#issuecomment-334376573. I haven't yet run these changes by a we= b spec person to make sure they're complete, so there might be another = set of PRs coming after these are in.

https://github.com/c= bor-wg/CBORbis/pull/17 has a lot of changes to define which kinds of CB= OR parsers need to detect which errors in the encoded data, and which error= s are recoverable.

The basic idea is to classi= fy encoded CBOR data into valid, invalid-but-well-formed, recoverably-ill-f= ormed, and fatally-ill-formed categories, and then use that in this and der= ived specifications to describe parser behavior precisely.

A question came up whether we can give an item's "unsigne= d integer" a better name. Any ideas?

https://g= ithub.com/cbor-wg/CBORbis/pull/18 defines when the known kinds of tagge= d items are valid.=C2=A0

Let me know what you thin= k. Approving PRs is probably helpful to the editors even if you have no comments.

Thanks,
Jeffrey

--001a114449ce57d10005691c5872-- From nobody Thu Apr 5 10:03:39 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0412DA28 for ; Thu, 5 Apr 2018 10:03:37 -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 HG2cw55AekFo for ; Thu, 5 Apr 2018 10:03:34 -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 2347B1271DF for ; Thu, 5 Apr 2018 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w35H3Tbi011742; Thu, 5 Apr 2018 19:03:29 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40H8Ks2bYCzDfRq; Thu, 5 Apr 2018 19:03:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 5 Apr 2018 19:03:28 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 544640606.682766-38fe01f77f57e8bc846f706a10052426 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] PR17 -- Re: Making CBOR parsing more rigorous X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 17:03:38 -0000 On Mar 23, 2018, at 18:04, Jeffrey Yasskin wrote: >=20 > https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to = define which kinds of CBOR parsers need to detect which errors in the = encoded data, and which errors are recoverable. There are lots of changes there. I like identifying the value derived of the head (first byte plus any = additional bytes that go into the additional information) of a data item = (what is currently called the =E2=80=9Cunsigned integer=E2=80=9D in your = text) by name. If =E2=80=9Cargument=E2=80=9D is the best we can do, = let=E2=80=99s go for it. > The basic idea is to classify encoded CBOR data into valid, = invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed = categories, and then use that in this and derived specifications to = describe parser behavior precisely. I don=E2=80=99t know that we need all these. I think that the impetus for this change stems from a misreading of = Section 3.3. This Section lists things to check for in a generic parser, but also = gives some advice on processing damaged data. With some malice, that can be read as specifying the soupification of = CBOR, but that was never the intention (and I haven=E2=80=99t met anyone = misreading it that way). Specifically, there is no intention to require = specific methods of salvaging (or making the standard behavior depend on = it). So I think the editorial improvement would be to indicate more clearly = in 3.3 what is about consistency requirements that must be checked (and = violate wellformedness if they fail) and what is about potential = degraded processing in the presence of an error. > A question came up whether we can give an item's "unsigned integer" a = better name. Any ideas? Let=E2=80=99s go for =E2=80=9Cargument" now; we can always globally = substitute that later. Gr=C3=BC=C3=9Fe, Carsten From kio@mothers-arms.co.uk Sun Apr 15 17:21:29 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABC312D7F2 for ; Sun, 15 Apr 2018 17:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kshpYJtzXH70 for ; Sun, 15 Apr 2018 17:21:27 -0700 (PDT) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51]) (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 0F860127775 for ; Sun, 15 Apr 2018 17:21:27 -0700 (PDT) Received: from a-webmail.mh.aa.net.uk ([2001:8b0:0:30::75] helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1f7rtd-0000uw-MW for cbor@ietf.org; Mon, 16 Apr 2018 01:21:25 +0100 Received: from cpc105066-sgyl40-2-0-cust671.18-2.cable.virginm.net ([82.1.242.160]) by webmail.aa.net.uk with HTTP (HTTP/1.1 POST); Mon, 16 Apr 2018 01:21:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_33d77a258431280065d5a5d23ced2676" Date: Mon, 16 Apr 2018 01:21:22 +0100 From: Kio Smallwood To: cbor@ietf.org Message-ID: <0e4a319951bc9558a732692a02d26309@mothers-arms.co.uk> X-Sender: kio@mothers-arms.co.uk User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [Cbor] Maps used as keys? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 00:26:38 -0000 --=_33d77a258431280065d5a5d23ced2676 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi All, Sorry to be late to the party but we recently fixed this issue for one of the Python implementations: https://github.com/agronholm/cbor2 Although we're very unlikely to use a python dictionary-like object as a key, it also encountered this problem if an array was being used as a key since by default, arrays are de-serialized into lists, and those are not usable as keys either. All mutable and unhashable types which can be used as keys in CBOR will be unpacked as equivalent immutable and hashable types. * list => tuple * bytearray => bytes * map => frozendict * set (tag 258) => frozenset cbor2 also supports custom tag handling which can be made aware that it is currently decoding a key and behave accordingly, as documented here: http://cbor2.readthedocs.io/en/latest/customizing.html#decoding-tagged-items-as-keys Hope that helps protocol implementers. Cheers, Kio --=_33d77a258431280065d5a5d23ced2676 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi All,

Sorry to be late to the party but we recently fixed this issue for one o= f the Python implementations: https://github.com/agronholm/cbor2

Although we're very unlikely to use a python dictionary-like object as a= key, it also encountered this problem if an array was being used as a key = since by default, arrays are de-serialized into lists, and those are not us= able as keys either.

All mutable and unhashable types which can be used as keys in CBOR will = be unpacked as equivalent immutable and hashable types.

* list =3D> tuple

* bytearray =3D> bytes

* map =3D> frozendict

* set (tag 258) =3D> frozenset

cbor2 also supports custom tag handling which can be made aware that it = is currently decoding a key and behave accordingly, as documented here: htt= p://cbor2.readthedocs.io/en/latest/customizing.html#decoding-tagged-items-a= s-keys

Hope that helps protocol implementers.

Cheers,

Kio



--=_33d77a258431280065d5a5d23ced2676-- From nobody Thu Apr 19 05:30:36 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB212D95C for ; Thu, 19 Apr 2018 05:30:33 -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.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152414103339.28652.2068777545811754669.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2018 05:30:33 -0700 From: IETF Secretariat Archived-At: Subject: [Cbor] Milestones changed for cbor WG X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 12:30:33 -0000 Changed milestone "Submit CDDL to IESG as an Informational or Proposed Standard RFC", set due date to May 2018 from October 2017, added draft-ietf-cbor-cddl to milestone. Changed milestone "Submit rfc7049bis to IESG as a Proposed Standard", set due date to October 2018 from May 2017, added draft-ietf-cbor-7049bis to milestone. URL: https://datatracker.ietf.org/wg/cbor/about/ From nobody Thu Apr 26 07:14:22 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C528124B17 for ; Thu, 26 Apr 2018 07:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RPHmxmbf; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y9ro85GR 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 80-hN9XF1__D for ; Thu, 26 Apr 2018 07:14:18 -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 08F8F1241FC for ; Thu, 26 Apr 2018 07:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1524752056; 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=Vyfy3l7xmxgRo//XO/Zxnh1xK0zCuHOOhgvQ6ea5cOM=; b=RPHmxmbf0gDeFeXAsAYX4doXasaTKca2OjB8FhyR3EdzLgIvYKOSoAQyadJTDx7t PQbpmKADb8s3Xu5+GKJwF+KUigBFzWgpqqr5K/Y1XvgEGPRYS/9gVxzE4ynn7tB+ qq04tYvQx5oBLv/pX4zR4UcNgxII06V2kqdb7+TF7mk=; X-AuditID: c1b4fb25-98ba79c0000064d0-5a-5ae1deb84f83 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.8B.25808.8BED1EA5; Thu, 26 Apr 2018 16:14:16 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSHC015.ericsson.se (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 26 Apr 2018 16:14:15 +0200 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Apr 2018 16:14:15 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 26 Apr 2018 16:14:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UOgMLCDZHcFBP6c5mU0UhOOz/e5Aw9GFEcFdrn4OQ2A=; b=Y9ro85GRrpeioMPxNGZiF9/T/oxTDpVU4XtZiOSnB7q36fZFFtQ799bsDR3AzM58HeAWXVbib202a3qyK8iMCRnPAUG8iKEsoRsBv23hatCSoSb+qbXizhpNR4XZ54YzkOlHTmiyklGZFyxl+ALMigaiOEzJLwC2rVWmfkvakTc= Received: from AMSPR07MB344.eurprd07.prod.outlook.com (10.242.20.149) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.10; Thu, 26 Apr 2018 14:14:14 +0000 Received: from AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a4cd:9b02:77:f1cf]) by AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::a4cd:9b02:77:f1cf%6]) with mapi id 15.20.0715.016; Thu, 26 Apr 2018 14:14:14 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" , "draft-ietf-cbor-7049bis@ietf.org" Thread-Topic: Progressing work on draft-ietf-cbor-7049bis Thread-Index: AdPdaLX8Y4h/ih/5T5G03fZliVt7Gw== Date: Thu, 26 Apr 2018 14:14:14 +0000 Message-ID: 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: [185.90.177.181] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 7:enjbPkjBJB9jvsM+ocVc/qB8lozxln/gtHM1F/JdekZslMmRStL/4cYvjXivszYTP8ujx6BZ2C5r0wtEMz0NGMOhcI65cVY8kXnqhDJ9jFjYXMUIfjOyhOElAmPrSjzPZFbIwocQvpwHI3PEz9NP260d4U4zgdiGhls5HBkGBHkGnwzqyeMEMbdyMFPBM7SCF6ZjVeayvFrrBeBIT0CAnrLDTIHzw6s0jvK+R05qIfI3KvOL+AzzTzFhjMjjjk1x x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AMSPR07MB455; x-ms-traffictypediagnostic: AMSPR07MB455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231232)(944501410)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(396003)(376002)(39380400002)(53754006)(199004)(189003)(19609705001)(5250100002)(4326008)(55016002)(86362001)(3280700002)(14454004)(450100002)(106356001)(74316002)(105586002)(2351001)(966005)(68736007)(2900100001)(6916009)(2501003)(99286004)(53936002)(5640700003)(790700001)(54906003)(33656002)(5660300001)(66066001)(6436002)(3846002)(6306002)(8936002)(2906002)(3660700001)(7696005)(59450400001)(486006)(478600001)(476003)(26005)(5630700001)(6506007)(102836004)(25786009)(6116002)(81156014)(606006)(236005)(1730700003)(8676002)(186003)(7736002)(81166006)(9686003)(44832011)(54896002)(316002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB344.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IEqDyZPE/5rUxDvrWTxxDaDnQH6eL1FqYuXqV5KvWDZruZrNHLCYJnvijCPB5vCyEjtV6pCdVc924yRe98BKkNXmbecyGOdt6tkAcHCCIsU29PT9xs3z8sKx0RngJ07NDM8VZ1zwJ2eQc8yQGDeam3bwTTB2TSMwjimBs06Z5tmFe0+kbFHoHbfktjJEhtsL spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMSPR07MB344D5C815F6B7BC657B21F9988E0AMSPR07MB344eurprd_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 80f9b7c1-800d-42a5-ef5c-08d5ab7ffd59 X-MS-Exchange-CrossTenant-Network-Message-Id: 80f9b7c1-800d-42a5-ef5c-08d5ab7ffd59 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 14:14:14.0644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee+9u7suR7eleNCUmOmydH4UOUGyiD4Io8B/ZEI19aLW/OBO RS1CQUM0TEMJp6CphGhm6KZWkmmhVtpMS1FDFA0xP2bLNBG13b0L/O/3nOc5nHNeXoaU1Ytc mYSkVI5P0mjltIQqj2wP8+uYmlEH7A64qCq2DUhVnv+YUm3uNhFnyEt1dZvENaSWhMZy2oR0 jvc/fVMS/2Wrj0j56Z/RaE7LRhafAsQwwJ6EzdE7BUjCyNj3CD6VDomwMCDIrTLSBcjBKtYR 9I8rsFFHwEplLiEIirUQMLlmpLBTQsDCo00xFt8RjJRMkUI/zYbC0IxZJLAT6wllpe9oYTjJ ZsHs9BEBD1r3WJ5PxIkQsPTvkJiV8COnwMYU6wUT3d+QwFJWDRO/flMCI9Yd1nIabRmSdYGJ uSpCYGBZqOs0kZidYWF2R4TzMfB1skiM63KwzG7Y2R2GqwqRsD6wrQT0GAoRNvxgtayMxIYR wYNek73DB/KL1+3TEmDs2RKNOQrGXjTaG2pJyKsoFGHjEGxl1xDYeE5D1cuPdDFS6vesrrc9 TDIMGQ7rbZcegA/lcxSO+EL1awuN+Tg8fbJI/ueBt7PE3no1EjcgZx2ni06MCzqh5PiEGJ0u OUmZxKW2IOv/6TZseXWgkaWzPYhlkNxRqh2fUctEmnRdZmIPAoaUO0k7Jq0laawmM4vjk2/w aVpO14PcGEruIp0JblXL2DhNKneb41I4/r9LMA6u2cixS+4ZtHi3fd+cRdHl23tdbSLviQfr s3gt138x6s2FmsseZuX+8JwGl4eV3nmmwmWpWb2WFRCx7bwy/Tfdf6w5srOW+BweXVv0R796 K6P51RVuN7hpd2P4lCIs8Gi9Yp6Kyh6PKB0dRHrvqyEtkef7PM4Z2ybcvLanp1Rt9w1yShev CTxG8jrNP5mZwgs7AwAA Archived-At: Subject: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 14:14:20 -0000 --_000_AMSPR07MB344D5C815F6B7BC657B21F9988E0AMSPR07MB344eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In order to progress the draft, I'd like you to take a look at Jeffrey's pr= oposals (quoted selected text from his mail below). Only PR17 has gotten one comment so far (let's discuss it further). Note th= at the PR were submitted more than a month ago, if I hear no objections to = them before the 11th of May, we'll ask the editors to go ahead and merge th= em, so please take a look and speak up. Even a "+1" is useful. Big PR: https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define w= hich kinds of CBOR parsers need to detect which errors in the encoded data,= and which errors are recoverable. https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds of = tagged items are valid. Minor PR: https://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data Model= s section. https://github.com/cbor-wg/CBORbis/pull/19 fixes an example of Javascript b= eing unable to distinguish strings from numbers when they're used as map ke= ys https://github.com/cbor-wg/CBORbis/pull/20/files changes a statement that d= epending on map order "would be very bad practice" in protocols using CBOR = to a statement that these protocols "MUST NOT" do that. Thank you, Francesca & Barry --_000_AMSPR07MB344D5C815F6B7BC657B21F9988E0AMSPR07MB344eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

In order to progress the draft, I’d like you t= o take a look at Jeffrey’s proposals (quoted selected text from his m= ail below).

 

Only PR17 has gotten one comment so far (let’s= discuss it further). Note that the PR were submitted more than a month ago= , if I hear no objections to them before the 11th of May, weR= 17;ll ask the editors to go ahead and merge them, so please take a look and speak up. Even a “+1” is useful.=

 

Big PR:

https://github.com/cbor-wg/CBORbi= s/pull/17 has a lot of changes to define which kinds of C= BOR parsers need to detect which errors in the encoded data, and which errors are recoverable.

 

https://github.com/cbor-wg/CBORbi= s/pull/18 defines when the known kinds of tagged items ar= e valid. 

 

Minor PR:

https://github.com/cbor-wg/CBORbi= s/pull/14 removes the duplicate Data Models section.=

 

https://github.com/cbor-wg/CBORbi= s/pull/19 fixes an example of Javascript being unable to = distinguish strings from numbers when they're used as map keys

 

https://github.com/cbor-wg/= CBORbis/pull/20/files changes a statement that depending = on map order "would be very bad practice" in protocols using CBOR to a statement that these protocols "MUST NOT= " do that.

 

Thank you,

Francesca & Barry

--_000_AMSPR07MB344D5C815F6B7BC657B21F9988E0AMSPR07MB344eurprd_-- From burt_harris@hotmail.com Mon Apr 30 13:43:52 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168521270AB for ; Mon, 30 Apr 2018 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 WublD7rTsCdB for ; Mon, 30 Apr 2018 13:43:50 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000027.outbound.protection.outlook.com [40.92.0.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9D8127078 for ; Mon, 30 Apr 2018 13:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VqYlyGv+aeptitODbr17cVVZWiI3mrQWm8WqKsx1aFQ=; b=u+8ldVTtY8mZveQof3AxP51LzjHUwHxjLRve5MYicG1+2bC2oe14/7NldnwMTZiTp8uKvP0SUeClf54DCKgX5b5mMv5HbM5oPNsa/3/oG/JPAMDh1sC6F4UIYr4nlYUhRdErIjBj6fCVulnkLW2QnOPs9vTyERsBdTOIxK94cLvYGz/vbypeT22X7jqaTkt2h8ffEv4STKgjgeQctiMJ97Ph10QHulmKi9yx68/IoETOs2dJnsr6580spKbKoO++KZX4gof9aAPbZAiPbkul+0acBvLYJr1QZ8YiFfSA2SN4FLnc78UP5fl762CynJ+BLlwtUq1MT3rbCx7kr3DWOw== Received: from SN1NAM01FT009.eop-nam01.prod.protection.outlook.com (10.152.64.55) by SN1NAM01HT183.eop-nam01.prod.protection.outlook.com (10.152.65.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.715.13; Mon, 30 Apr 2018 20:43:48 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.64.60) by SN1NAM01FT009.mail.protection.outlook.com (10.152.65.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.715.13 via Frontend Transport; Mon, 30 Apr 2018 20:43:48 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1%18]) with mapi id 15.20.0696.020; Mon, 30 Apr 2018 20:43:48 +0000 From: Burt Harris To: "cbor@ietf.org" Thread-Topic: Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? Thread-Index: AdPgwRs737ku8ludTkugZp5tVfTGkQ== Date: Mon, 30 Apr 2018 20:43:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:0F3943BDBC688EB3A866C6DE51EB77467E5CE814350E181353D6DC7F3874567D; UpperCasedChecksum:97BD1A236119137B1BE051E1D4788C16712D4123E3C6F730922E07F360344D93; SizeAsReceived:6901; Count:43 x-tmn: [5PW/I1MGAfANmoubptth1uunCS1pMd5y] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT183; 7:Ux2xg8IYXj94YctSmoRusuKNUEXIYXSKgNEM9CECghqObxx86kBalssozCtIiAPYFNaN7NWuHLaWe/ULpTXljhEEUDct0GGexNyISXM4xISGvpEDdJoeeySKf/C1IvgH/quR6IpSYwfD2hxlG0AU0HQweRu3GjnTWnUv+nk0QpqfhoQ/O5qdKCaHVh/boi12qwv99PHhwK/lKE+9O89YVEhlH0OADWvvyMWMonHbt0azmHgRNImwbz6HaeY8+SCu x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SN1NAM01HT183; x-ms-traffictypediagnostic: SN1NAM01HT183: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM01HT183; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT183; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT183; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: jYMXu4EaJoeqRsZdzSE8osSxq/zFVWyYewese4RlyfR6EZvTUgVAOMyTjCiya/79FriqR00++CjwuUleatizVVCC1g0sxc7SFHKWrunw5WnWNUReJeGJHalrH0ky23L0jRlGulvBAcUZPqNCyykHzLzN2k/FC6d8hi51zBHp/r4qODFLy1Fm1u0vG+MsA/cB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4186c73c-edd7-476a-6f53-08d5aedb135f X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 4186c73c-edd7-476a-6f53-08d5aedb135f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2018 20:43:48.7635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT183 Archived-At: Subject: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 20:55:02 -0000 After reading RFC 7049, it seemed apparent to me that the JSON string type = would generally be encoded in CBOR as major type 3 (text string). =20 However reviewing section 4.2, which is specifically about converting JSON = to CBOR, nowhere does this rule seem stated explicitly. I would normally = not have considered this a problem, but I encountered examples in one of th= e tag definition documents uses where th= e author seems to interpret the RFC as saying that CBOR major type 2 (byte = string) may be used as an alternative. =20 Take for example, the 3-charactar JSON content "1" (with quotes included in= the JSON.) I've been surprised about how adamant the other author has = been that this may be encoded as 41 31, when it seemed clear to me that 61 = 31 was the canonical encoding. =20 I therefor wonder if it might be a good idea to add language to the CBOR bi= s document saying that JSON strings should always be encoded as CBOR major = type 3, and that in general major type 2 would be unexpected in the result = of a JSON to CBOR translation. =20