From nobody Wed Jul 5 02:49:25 2017 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 DF7F7132092; Wed, 5 Jul 2017 02:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N92vGTCE2GaN; Wed, 5 Jul 2017 02:49:20 -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 6750C132091; Wed, 5 Jul 2017 02:49:20 -0700 (PDT) X-AuditID: c1b4fb2d-bcf0a9c000005faa-59-595cb61e8856 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A3.17.24490.E16BC595; Wed, 5 Jul 2017 11:49:18 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 5 Jul 2017 11:48:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RlEz38OlgI+Bio3k3O/sbQJ96D+kMeZHyQ6HEEHhf5c=; b=jUh3dAcrVqafzRLPKfbC+vwQF/rePTFAT5QwabUVQqS37HeIEQKD2x21VcwNI8Ra3UmKzQpxCzpfQtqglRpSJDLdAyRcvHQfZzKtBp2kfnX6e2kcEMPPNYhqlmE6OzoXAZMA/JiB6G6QPVMiDzdxX4Y4fw638lsysh9rO/XUk9s= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2297.eurprd07.prod.outlook.com (10.168.127.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Wed, 5 Jul 2017 09:48:29 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::97a:6d49:76af:674]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::97a:6d49:76af:674%17]) with mapi id 15.01.1240.013; Wed, 5 Jul 2017 09:48:29 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBDb25maXJtYXRpb24gY2FsbCBmb3IgV29ya2luZyBHcm91cCBBZG9w?= =?utf-8?Q?tion_for_draft-greevenbosch-appsawg-cbor-cddl?= Thread-Index: AdL1cdNAE+Oa5k9GSgKtnPjDmRW2CA== Date: Wed, 5 Jul 2017 09:48:29 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.216.64.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2297; 7:qJdNvJPui6OtkRxfHvpjBEge/L0x3IoG8HI9h4Z580r2T5pG/3plEmCRO0qzSIeZiX1hgeDmXHMXxhWCgNBOC3pRjzT9U1ydJHku+GOIs1QOzpqXSnkUGXArlHX18CJD/Ed0I3kMDKetDajwGEFZOsvQnwDMSFV2Nv0eaMDBfuMaRKKexoCq0mVVoA8TG9KXqEOIw9GRaWWA7ekeMEthLbI2mbeelp2KZgXIowQiP9VReunhGnfclqNsP88sEbdMyyr6G+U74kmB/riSDkxCXYG2xTNCaf8aQgrGHHH3NAWUnbkxIOG+SHNOME2T0OQ4/2QDRdVe3QLkjN6nJ98zWtDIy5j/aX0rCzHKVS9HyUGDSgG+Ghp0acxNqZpM1tlYAT/F0n4Y/dJbD0HC6L7DN0hJ0SPq2CU2z+pFvPK6HpHyAPMaWU7mWZKFVjNWkaIhkcTv2xCR+DIpeUjLZNed0KX/28EoI0A7Kx+nvulWqJEkufGKw182rUXjd2T/2mxGGxrlyVeXOc6ELyTKgaD83s+KNm7j3x2MXkII8F5SaZKrcjaCwfzZpBATyCjM81xhkAn5dZlwdufGov7KlKBJrr61pJIyss95TvCtfvr4dA0ZRRTlNz7OM37kHDeIY1qJAOZzhuIUAmduiiW4yAVKQMWK8E28EWOBpOtUro4xtWzNpc3HwILaOKlo12wroKeaqUT/5d5oN5w69gTQWjLAbK1KgJ1Cij1wxelVQ+FQ8H9dWLyQ3/tLbvQ6IhlVv2jYcujVWvg8L00puILlfVauh3u9mDR5M3uJTAoZXrV5MXA= x-ms-office365-filtering-correlation-id: 74daee0a-3e68-4de0-38b9-08d4c38afdb9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB2297; x-ms-traffictypediagnostic: HE1PR0701MB2297: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(26388249023172)(236129657087228)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910033)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2297; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2297; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(39410400002)(53754006)(54896002)(2906002)(236005)(66066001)(74316002)(9686003)(6306002)(7736002)(25786009)(5250100002)(7696004)(229383001)(450100002)(55016002)(106356001)(3846002)(6116002)(102836003)(790700001)(53936002)(2351001)(86362001)(4326008)(99286003)(33656002)(19609705001)(230783001)(38730400002)(3280700002)(5640700003)(3660700001)(110136004)(14454004)(6436002)(54356999)(6916009)(8936002)(2501003)(81166006)(50986999)(1730700003)(6506006)(189998001)(606006)(2900100001)(478600001)(5660300001)(966005)(5630700001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2297; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25390DA8E0A1BEDE50EF206D98D40HE1PR0701MB2539_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2017 09:48:29.4197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2297 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0iTURjmfPu2fUqT49R88Vrz0hQvqYUaEvqn/JNJv7SEXPk1Jd1sn0kr Asu8zpmoIZtpkgsyQ20tb2gxjXJmZGpCq0jnhSJBK7G8Vdu+Bf57nvNcznlfDsURtnG9qBxZ Aa2QSXJFPGdSk9YTGO7XnZG+f2lMHNe4bUBxmvIGMpFI1unWiVR00jkhi87NKaQVkYcznbMn BhZQ/ot9l5a1G0QR6gquRE4U4AMw0m4kKpEzJcTPEZTrf/NY8hJB3WqTnZBYzYEps96haAiw 1AzyWWKxZszjpK2MhxNgfHaZa8PuOABu1Q9bExTFwVGwPnDB5nfDagQzjTeRjbjjWgQNhlYe G4iA5tl+jg2TOBA6qlbsRQKcCSVLDXYPwr6weq3d7uFgTzDP3yHYKTDoBt5wWOwBX+f+cG0X IKxCsNI87TDtgV8bIySLfWHijsr+CsAWHoze7XKkj4F2uJ1ghUkC5iZrHUIY6Eu/81gsh4bP PxzpagRNxhY+S95xYXLtOmJdPmD+0OuoquZBSe1Pe5Ub9oJPUxWIxT7w5eMgtwaJtTuGYrEc Hi0WI619Ca5g0syTWvs2Q6CzP5K17IV61SyfxWIoud3E33negvgPkAdDM0yeNDomglbknGUY uSxCRhfokfUDGQ2b4b2o/VvSEMIUEu0S0E8y0oVcSSGjzBtCQHFE7oJ4g/VIkCVRXqYV8tOK i7k0M4S8KVLkKUh8Op4mxFJJAX2epvNpxX+VoJy8ipDyoKZkW3dqPnamIr4HkkyRIclvzWjM ZeRZ14kUfYI4QJo1fUTut2kkr6g7zy3WGVxc7/WlvQq7Wlx2/BDUGGurZGXqNtOWcjhVniEV ZMUcfWheC1KeiV3Yii71LkscDVrvMwlbd6v+9lrK/PtC36sfOw34B7/euJ+yauq+0SEimWxJ VChHwUj+AZkcgr48AwAA Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Group?= =?utf-8?q?_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?= 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: Wed, 05 Jul 2017 09:49:23 -0000 --_000_HE1PR0701MB25390DA8E0A1BEDE50EF206D98D40HE1PR0701MB2539_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBdCB0aGUgSUVURjk4IG1lZXRpbmcsIHdlIGhhZCBpbi1yb29tIGNvbnNlbnN1 cyB0byBhZG9wdCBkcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwgYXMgYSBzdGFy dGluZyBwb2ludCB0byB3b3JrIG9uIENCT1IgZGF0YSBkZWZpbml0aW9uIGxhbmd1YWdlLiBUaGUg YXV0aG9ycyBoYXZlIG5vdyB1cGRhdGVkIHRoZSBkb2N1bWVudCBhbmQgZmVlbCB0aGlzIGlzIHJl YWR5IHRvIGJlIGEgd2cgaXRlbS4NCg0KVGhpcyBpcyBhIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBh ZG9wdGluZyB0aGlzIGRyYWZ0IGFzIGEgd29ya2luZyBncm91cCBpdGVtLiBJZiB5b3UgZG8gbm90 IGFncmVlIHdpdGggdGhlIGluLXJvb20gY29uc2Vuc3VzIHRoYXQgd2UgaGFkIGluIENoaWNhZ28g dG8gYWRvcHQgdGhpcyBhcyBhIFdHIGRvY3VtZW50LCBwbGVhc2Ugc3BlYWsgdXAgdW50aWwgMjAx Ny0wNy0xOS4gSWYgeW91IHdlcmVu4oCZdCBpbiB0aGUgcm9vbSBidXQgZG8gYWdyZWUgd2l0aCBh ZG9wdGluZyB0aGlzIGRvY3VtZW50LCB5b3UgY2FuIGFsc28gdGVsbCB1cy4NCg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbC0x MQ0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg== --_000_HE1PR0701MB25390DA8E0A1BEDE50EF206D98D40HE1PR0701MB2539_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoZSBJRVRGOTggbWVldGluZywg d2UgaGFkIGluLXJvb20gY29uc2Vuc3VzIHRvIGFkb3B0IGRyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBz YXdnLWNib3ItY2RkbCBhcyBhIHN0YXJ0aW5nIHBvaW50IHRvIHdvcmsgb24gQ0JPUiBkYXRhIGRl ZmluaXRpb24gbGFuZ3VhZ2UuIFRoZSBhdXRob3JzIGhhdmUgbm93IHVwZGF0ZWQgdGhlIGRvY3Vt ZW50IGFuZCBmZWVsIHRoaXMgaXMgcmVhZHkgdG8gYmUgYSB3ZyBpdGVtLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIGEgY29uZmlybWF0aW9uIGNhbGwgZm9yIGFkb3B0aW5nIHRoaXMg ZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0uIElmIHlvdSBkbyBub3QgYWdyZWUgd2l0aCB0 aGUgaW4tcm9vbSBjb25zZW5zdXMgdGhhdCB3ZSBoYWQgaW4gQ2hpY2FnbyB0byBhZG9wdCB0aGlz IGFzIGEgV0cgZG9jdW1lbnQsIHBsZWFzZSBzcGVhayB1cCB1bnRpbCAyMDE3LTA3LTE5LiBJZiB5 b3Ugd2VyZW7igJl0IGluIHRoZSByb29tDQogYnV0IGRvIGFncmVlIHdpdGggYWRvcHRpbmcgdGhp cyBkb2N1bWVudCwgeW91IGNhbiBhbHNvIHRlbGwgdXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncmVldmVuYm9zY2gt YXBwc2F3Zy1jYm9yLWNkZGwtMTEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1n cmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwtMTE8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5jZXNj YSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR0701MB25390DA8E0A1BEDE50EF206D98D40HE1PR0701MB2539_-- From nobody Thu Jul 6 05:49:54 2017 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 612F313162D; Thu, 6 Jul 2017 05:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hbl_qTfngIX; Thu, 6 Jul 2017 05:49:50 -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 1679212EB43; Thu, 6 Jul 2017 05:49:49 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-15-595e31ecbff9 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.6A.07915.CE13E595; Thu, 6 Jul 2017 14:49:48 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 6 Jul 2017 14:49:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pgXpl27/i07u+xRo47sv5CaWkjWENqwyawiOLw2kvQM=; b=fc9QLdGwYhURkK42a+ZsQrw/RJOfkKD5dPdTVExTe/lc+wGFNKdN27WS/gOIJcQSa97tpoHgSjl1ZmsTnJ89eT7ZtSTQFLerxkLtqoEYjggNqnPy1AIvdq1Qv1XV6Qc22tK//EdWIVxTOf2OPwVx58CwqIKde3QqT9xpUy1yCzQ= Received: from DB6PR0701MB2535.eurprd07.prod.outlook.com (10.168.76.23) by DB6PR0701MB2902.eurprd07.prod.outlook.com (10.168.83.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 12:49:46 +0000 Received: from DB6PR0701MB2535.eurprd07.prod.outlook.com ([fe80::ced:ebf2:17cc:8e7a]) by DB6PR0701MB2535.eurprd07.prod.outlook.com ([fe80::ced:ebf2:17cc:8e7a%17]) with mapi id 15.01.1240.013; Thu, 6 Jul 2017 12:49:46 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Slot requests for IETF99 Thread-Index: AdLtt7O52CIZ/CWwSe+7lD2M/GgOxgInkYOw Date: Thu, 6 Jul 2017 12:49:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2902; 7:WSaH3QrRl37aazP3cR2e7QE22RDs/+jkhfs1ig8eAz9mTFQZz51MdaigpBnY/0VIH8qpMnCfgjuH24Q3H+HpGbnLMHwk+vuGHtnO1gKnvi4+1w/ACliMoIMYNPN2Z5XLD+AF15JyWHVKfD73Rif5i7L2WLLSJWbmEopsk7waZCroGitn/0I9XWCPr+847gA5ZCzbPnbCqXM6TfGxvUXIKSdIII3dyduohrqCfwxLwYs/eEc2wDu2BfKUQ5SXF3v11mkSFQj34H4TNDgFdJU2G4F+/Btd+balU8w702b5qYymZhqt00G+b9TAqgF7oFVe/fjjFg68ROUJNu/Ds3pNdFPjHCi21QcHqDelbbbGyIptlgVVZMoWhg8KwJySOqIxYKZsJUa9kkNEGUjcx+slQXKnpnq+QHZZ2YVVCGPWxc7nPoc8Fzm5Ps4vk4gY8xxLAFh1A1WmAq302XQiyLSbB8AieSeJemhxpzwoLxhul3QKJg3m/C66pATeCS0ix1uHW9AGeiw6iHdqsF7Qimxrqw1g0oHbt2IG39xsjkF1lBhWkjdydoe9FJA+3kJG6aDFkz7DO3XTjxMv02D3JA16htWDv978tZIo6pU6jAL8QIS8/oZ+P+HFa01FJM0iTm+WAv41TSaNfKWXWMRg7dco+4dM31k+JcNs3dzQmcEd8Olvcp92NxU/EBHa0oyCxzR00X6IS/8hmeje2QbWKxbfwOloBy+Tp5Eg5CKywezqPSRmRgdivhl5K6vHM5rKHVC47SOOyOrhrKmp7bFsjlhmuuUiyGRS2lt9LMmlhS2AyzA= x-ms-office365-filtering-correlation-id: bb3e36f6-25cf-47e6-85ea-08d4c46d7b71 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2902; x-ms-traffictypediagnostic: DB6PR0701MB2902: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(278178393323532)(120809045254105)(26388249023172)(236129657087228)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2902; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2902; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39400400002)(39410400002)(39850400002)(39450400003)(39840400002)(66544003)(53754006)(25786009)(66066001)(189998001)(53546010)(4326008)(14454004)(6436002)(7696004)(606006)(6916009)(7736002)(2950100002)(38730400002)(110136004)(450100002)(19609705001)(966005)(5250100002)(2900100001)(86362001)(5630700001)(478600001)(2501003)(9686003)(229853002)(6246003)(54356999)(53936002)(6116002)(99286003)(790700001)(102836003)(74316002)(3846002)(81166006)(55016002)(1730700003)(54896002)(6306002)(8676002)(236005)(8936002)(5660300001)(5640700003)(33656002)(6506006)(2351001)(76176999)(3280700002)(3660700001)(2906002)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2902; H:DB6PR0701MB2535.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB2535062F2528D72F9DBD33EC98D50DB6PR0701MB2535_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 12:49:46.5377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2902 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69u16Xg6epeLSMsWnku7MoP0jklxKhNCjQInXmTYe66WYj +zQNSWamZKWbqRO1D4agNdFKJbfABK3Rmkql6VyRuGVICCq9bLsT+vY75//jcJ7Dw5DCPl4E I1dUsSqFrExM8yl9zggkuKR5ucl18+Gp7b9NKFVf30qdIjJ6e7eJbHSJn1bElsk1rCrpZAG/ pGU7qMKZcGPA0U5qUe0RHQpkAB8Dq2uT0iE+I8SvESw0LhNcMYXAuvzZV1C4kYSpT2Z/0kaA oX6a5gongra2JeQdRuM0sK5s8LwcgiXw4L7FIzEMiaWwPVbpxWAcDT0zKs44DM2mWb+dAk0b Dh9TOAoGP0zRXhbgAlgbvkd4WejhQaOV9HIgloGxp8nHCEfCr5onPiZxGHx0dhHc0zD0jr0j OQ6FtdU/PO/KCDcg+Nk555dE8GWnxS9FwvuuBuSVADto0C00UlxwFobq7f7ARsBWx97YeKhd eeSXlLD13EVy0l0ErqUfAVxh58G8zYY46yB0DO34AxMNjrkXdDOKNfy3vMF3MiW417MMvhvs h2m9k+KUeDC+3KQ5joPH3evkHs+8WiX+7xtRQD8KVbPqwvLilKOJrEp+Va1WKhIVbNVT5Pk8 k6bd6FFkc6WbEWaQOEjwJiovV8iTadTV5WYEDCkOEQyHe1qCIln1TValzFddL2PVZnSAocRh gvQJa44QF8uq2FKWrWBVeynBBEZoUeY+rTI1Pj25YvzZiQsx39x/Y0YUFvmhWynFBo2t1X5F rp2QTC7eWXo7anFniik9q9xd0gzcvmbujOi3UOct2bUldaLZr0rnRQnOp7u1aYbBje/T0YXu UunxrTg7K9KIEnh9wqR5N69GUhm6eFmnecjvyzhzevwcDs7imcSUukQmjSVVatk/XxI8dzgD AAA= Archived-At: Subject: Re: [Cbor] Slot requests for IETF99 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, 06 Jul 2017 12:49:52 -0000 --_000_DB6PR0701MB2535062F2528D72F9DBD33EC98D50DB6PR0701MB2535_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A draft agenda for the CBOR meeting at IETF99 in Prague can be found here: = https://datatracker.ietf.org/meeting/99/agenda/cbor/ Please, send us comments or edits about it by Monday July 10th. Thanks, Francesca From: Francesca Palombini Sent: den 25 juni 2017 15:35 To: 'cbor@ietf.org' Cc: cbor-chairs@ietf.org Subject: Slot requests for IETF99 Hi all, We are starting to plan the CBOR session for the IETF99. If you are interes= ted in having a presentation slot, please send a request to the chairs by T= uesday July 4th, with the following details: - Draft - Abstract: A couple of lines about the document or topic. - Objective: Present an idea, get adoption, ask for feedback/reviewers/... - Time: How much time you think you will need See you soon in Prague, Francesca & Joe --_000_DB6PR0701MB2535062F2528D72F9DBD33EC98D50DB6PR0701MB2535_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A draft agenda for the CBOR meeting at IETF99 in Pra= gue can be found here: https://da= tatracker.ietf.org/meeting/99/agenda/cbor/

 

Please, send us comments or edits about it by Monday= July 10th.

 

Thanks,
Francesca

 

From: Francesca Palombini
Sent: den 25 juni 2017 15:35
To: 'cbor@ietf.org' <cbor@ietf.org>
Cc: cbor-chairs@ietf.org
Subject: Slot requests for IETF99

 

Hi all,

 

We are starting to plan the CBOR session for the = IETF99. If you are interested in having a presentation slot, please send a = request to the chairs by Tuesday July 4th, with the following details:

 

- Draft

- Abstract: A couple of lines about the document = or topic.

- Objective: Present an idea, get adoption, ask f= or feedback/reviewers/...

- Time: How much time you think you will need

 

See you soon in Prague,

Francesca & Joe

--_000_DB6PR0701MB2535062F2528D72F9DBD33EC98D50DB6PR0701MB2535_-- From nobody Thu Jul 6 14:33:22 2017 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 97305129B43 for ; Thu, 6 Jul 2017 14:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 84Pg-t-S-Ltt for ; Thu, 6 Jul 2017 14:33:18 -0700 (PDT) Received: from server.obj-sys.com (server.obj-sys.com [74.50.121.244]) (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 9090D12EB9B for ; Thu, 6 Jul 2017 14:33:18 -0700 (PDT) Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:57628 helo=[10.0.0.100]) by server.obj-sys.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dTEOj-0007SA-CQ for cbor@ietf.org; Thu, 06 Jul 2017 17:33:17 -0400 From: Kevin Braun To: cbor@ietf.org Message-ID: Date: Thu, 6 Jul 2017 17:33:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Antivirus: Avast (VPS 170706-0, 07/06/2017), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.obj-sys.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - obj-sys.com X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: kbraun@obj-sys.com X-Authenticated-Sender: server.obj-sys.com: kbraun@obj-sys.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Cbor] Some questions on CDDL 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, 06 Jul 2017 21:33:21 -0000 Hi folks, I am investigating CDDL and have several questions and comments. 1. When a value (e.g. a text string, byte string, integer, or float) appears in a rule, what does that means for the CBOR data? The document doesn't make this explicit. I experimented using the CDDL tool (0.8.5) and that didn't bring clarity. For example, this rule: top = { 1 => "turkey" } validates both of these instances: { 1 : "turkey" } { 1 : 'turkey' } I would have thought the second instance ought to be invalid, since a byte string was found where a text string is expected, but the CDDL spec isn't decisive on this. Meanwhile, using the following rule, neither of the above instances will validate: top = { 1 => 'turkey' } In both cases, the error is: CDDL validation failure (nil for {1=>"turkey"}): ["turkey", [:bytes, "turkey"], nil] 2. Related to the above question, numeric handling is confusing. On the one hand, top = { ? "test" : [*mix-int-float] } mix-int-float = 1 / 2 / 10.0 will validate { "test" : [ 1, 2, 10.0, 1.0, 2.0, 10 ] } which suggests that a literal float can validate an integer value and vice-versa. But then, if I try defining this: mixed-range = 1..10.0 CDDL tool gives me an error: Incompatible range [Integer, Float]. For a range, integers and floats seem to be treated distinctly. I don't know whether this reflects the CDDL specification's intention or is just a limit of the tool. Also, this rule: top = { 1 => "turkey" } will not validate { 1.0 : "turkey" } which suggests that a literal integer will NOT validate a float value, contrary to how mix-int-float is handled. However, the following DOES validate the same instance: top = { one => "turkey" } one = 1 / 10.0 which just further muddies the waters. Again, this might all be due to limitations or bugs in the CDDL tool, but the CDDL spec doesn't make clear what should happen in these cases. 3. CDDL tool reports an error if you try to use an mapentry without a key inside a map, such as in: top= {mygroup, secondgroup} mygroup = ("thing-one" : uint, "thing-two" : tstr) secondgroup = (uint, tstr) This is sensible, but I don't think the specification actually forbids this; perhaps it should. 4. When a map has duplicate keys, CDDL tool will generate data using the last definition of the key. I didn't find an instance it would validate, though. Perhaps the specification should require an error in such cases. Example: top = { "thing" : uint, "thing" : tstr } Generated value: {h'7468696E67': "tic"} 5. CDDL tool reports an error (`block in grpent') when trying to generate instances for the following schema. I think it is valid CDDL and this is probably just a bug in the tool: top = { topgroup } topgroup = ( first: tstr, second: tstr, (option1: uint // option2: uint) ) 6. Are there restrictions on the use of '&' to create a choice from a group? I think some sensible restrictions would be: - every mapentry in the group must have a key type which must be a single-value - the group cannot use group choice (//) - the mapentry values must be unique, single-value types? At least, I think the above rules would be consistent with the intent of the "&" operator as described. 7. What happens when you have an empty group? Section 3.9 Socket/Plug would lead one to believe that an empty group cannot be matched, since it says that an undefined socket symbol is "taken to be an empty type choice (group choice)" and "It is not an error if there is no definition for a socket at all; this then means there is no way to satisfy the rule (i.e., the choice is empty)." But, the CDDL tool does not behave the same when a socket symbol is undefined and when it is defined as empty. The following instance: { "one" : 7, "two" : "seven" } is validated by: top = { one: uint, two: tstr, extra-junk } extra-junk = () and by: top = { one: uint, two: tstr, $$extra-junk } $$extra-junk //= () but not by: top = { one: uint, two: tstr, $$extra-junk } ; $$extra-junk undefined The description of an undefined socket as equivalent to an empty choice seems inconsistent with the observed behavior. I don't see an inherent problem with this behavior; I just think that explaining the undefined symbol behavior in terms of an empty choice group is inaccurate and probably misleading (assuming the CDDL tool is work as desired). Regards, Kevin From nobody Thu Jul 6 15:15:36 2017 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 89E71126D73 for ; Thu, 6 Jul 2017 15:15:34 -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 2R8OyJvP_11I for ; Thu, 6 Jul 2017 15:15:32 -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 36BF5124217 for ; Thu, 6 Jul 2017 15:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v66MFSMo000169; Fri, 7 Jul 2017 00:15:28 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3x3X9r4f3xz3ZBb; Fri, 7 Jul 2017 00:15:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jul 2017 00:15:27 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 521072127.179319-fa39e4dea1ad2ddf3ea6d98a06fcdbb6 Content-Transfer-Encoding: quoted-printable Message-Id: <6870432F-AB25-4F58-B377-9B163A303D87@tzi.org> References: To: Kevin Braun X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] Some questions on CDDL 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, 06 Jul 2017 22:15:34 -0000 > On Jul 6, 2017, at 23:33, Kevin Braun wrote: >=20 > Hi folks, >=20 > I am investigating CDDL and have several questions and comments. >=20 > 1. When a value (e.g. a text string, byte string, integer, or float) = appears in a rule, what does that means for the CBOR data? The document = doesn't make this explicit. I experimented using the CDDL tool (0.8.5) = and that didn't bring clarity. For example, this rule: > top =3D { 1 =3D> "turkey" } > validates both of these instances: > { 1 : "turkey" } > { 1 : 'turkey=E2=80=99 } Bug. Only the first one is valid with this description. > I would have thought the second instance ought to be invalid, since a = byte string was found where a text string is expected, but the CDDL = spec isn't decisive on this. Do you have a suggestion what we should add to the spec? The CBOR spec is quite clear that byte strings and text strings are not = the same; we could add an example that demonstrates this with CDDL as = well (e.g., your example). > Meanwhile, using the following rule, neither of the above instances = will validate: > top =3D { 1 =3D> 'turkey' } > In both cases, the error is: > CDDL validation failure (nil for {1=3D>"turkey"}): > ["turkey", [:bytes, "turkey"], nil] This is another expression of the same bug. > 2. Related to the above question, numeric handling is confusing. On = the one hand, > top =3D { ? "test" : [*mix-int-float] } > mix-int-float =3D 1 / 2 / 10.0 > will validate > { "test" : [ 1, 2, 10.0, 1.0, 2.0, 10 ] } > which suggests that a literal float can validate an integer value and = vice-versa. =20 This is indeed an interesting question. In a CBOR data model, ints and floats are rather different. In a JSON data model, they nominally aren=E2=80=99t (although they are = very much in many practical applications of JSON). We will need to make a few decisions here. I would tend to go for a complete separation of integer and float, but = we do need to make up our mind how JSON fits in there. (We also, in all = likelihood, need conversion operators or some such. Ouch.) > But then, if I try defining this: > mixed-range =3D 1..10.0 > CDDL tool gives me an error: Incompatible range [Integer, Float]. For = a range, integers and floats seem to be treated distinctly. I don't = know whether this reflects the CDDL specification's intention or is just = a limit of the tool. Right, as with strings, the tool is a bit =E2=80=9Csimple-minded=E2=80=9D = (read: broken) with its idea of equality. > Also, this rule: > top =3D { 1 =3D> "turkey" } > will not validate > { 1.0 : "turkey" } > which suggests that a literal integer will NOT validate a float value, = contrary to how mix-int-float is handled. However, the following DOES = validate the same instance: > top =3D { one =3D> "turkey" } > one =3D 1 / 10.0 > which just further muddies the waters. Again, this might all be due = to limitations or bugs in the CDDL tool, but the CDDL spec doesn't make = clear what should happen in these cases. Nice demos for why I=E2=80=99m in the process of rewriting parts of the = tool at this very moment=E2=80=A6 The current tool essentially exposes idiosyncrasies of the data model of = the programming language it is written in; instead, it needs to be based = on the more explicit choices we make. > 3. CDDL tool reports an error if you try to use an mapentry without a = key inside a map, such as in: > top=3D {mygroup, secondgroup} > mygroup =3D ("thing-one" : uint, "thing-two" : tstr) > secondgroup =3D (uint, tstr) > This is sensible, but I don't think the specification actually forbids = this; perhaps it should. Yes, the spec should say that a group needs member keys in order to be = used in a map. > 4. When a map has duplicate keys, CDDL tool will generate data using = the last definition of the key. I didn't find an instance it would = validate, though. Perhaps the specification should require an error in = such cases. Example: > top =3D { "thing" : uint, "thing" : tstr } > Generated value: > {h'7468696E67': "tic=E2=80=9D} Another tool bug. First, the member key should not transmogrify into a = byte string. The CDDL spec is bad in that it can never be satisfied. It is not = really =E2=80=9Cwrong=E2=80=9D in any other way, and it might be hard to = detect this particular error in a more general case. The tool has a bug here in that it enters a key into the map without = checking whether it was present already. > 5. CDDL tool reports an error (`block in grpent') when trying to = generate instances for the following schema. I think it is valid CDDL = and this is probably just a bug in the tool: > top =3D { topgroup } >=20 > topgroup =3D ( first: tstr, second: tstr, > (option1: uint // > option2: uint) ) There is a nice =E2=80=9CXXX=E2=80=9D in that source line 1038 :-) It just doesn=E2=80=99t know how to handle a group choice here. (Group choices came in when the logic already was based on knowing there = weren=E2=80=99t any and not all cases are actually implemented at this = point.) > 6. Are there restrictions on the use of '&' to create a choice from a = group? I think some sensible restrictions would be: > - every mapentry in the group must have a key type which must be a = single-value Why do you want this restriction? (It doesn=E2=80=99t hurt very much, but I also think it doesn=E2=80=99t = help.) > - the group cannot use group choice (//) > - the mapentry values must be unique, single-value types? Yes. > At least, I think the above rules would be consistent with the intent = of the "&" operator as described. >=20 > 7. What happens when you have an empty group? Section 3.9 Socket/Plug = would lead one to believe that an empty group cannot be matched, since = it says that an undefined socket symbol is "taken to be an empty type = choice (group choice)" and "It is not an error if there is no definition = for a socket at all; this then means there is no way to satisfy the rule = (i.e., the choice is empty)." But, the CDDL tool does not behave the = same when a socket symbol is undefined and when it is defined as empty. = The following instance: > { "one" : 7, "two" : "seven" } > is validated by: > top =3D { one: uint, two: tstr, extra-junk } > extra-junk =3D () > and by: > top =3D { one: uint, two: tstr, $$extra-junk } > $$extra-junk //=3D () > but not by: > top =3D { one: uint, two: tstr, $$extra-junk } > ; $$extra-junk undefined An empty group is very different from an empty group choice. CDDL does not currently provide a notation for an empty group choice = (which would be the bottom or =E2=80=9Cfail=E2=80=9D symbol in a = grammar), so the last test case is the only way to get one. An empty group, however, is approximately a no-op. It can be very much = a part of a group choice, besides other alternatives... (There can=E2=80=99t be an empty type, as a type is always matched by = exactly one data item.) > The description of an undefined socket as equivalent to an empty = choice seems inconsistent with the observed behavior. I don't see an = inherent problem with this behavior; I just think that explaining the = undefined symbol behavior in terms of an empty choice group is = inaccurate and probably misleading (assuming the CDDL tool is work as = desired). See above. Thank you Kevin; I=E2=80=99ll turn most of your message into a number of = failing tests for the CDDL tool (which will then hopefully be fixed by = the partial reimplementation). The question of equality of ints and floats (and, maybe even more = difficult, bignums and decimals and bigfloats) needs some thinking and = appropriate spec updates. I=E2=80=99d love to hear more about the use = case where you ran into the current implementation idiosyncrasies around = these equality issues; those might help us make the right choices there. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 6 16:01:34 2017 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 804E112F17A for ; Thu, 6 Jul 2017 16:01:32 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=b6+t2HcF; dkim=pass (1024-bit key) header.d=chromium.org header.b=UX2tPdOl 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 VUZhi2MWytZb for ; Thu, 6 Jul 2017 16:01:31 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 C257E12EC34 for ; Thu, 6 Jul 2017 16:01:30 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id r103so22950374wrb.0 for ; Thu, 06 Jul 2017 16:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=q+KjCMZrTzz8REx2zaFd0hkyHnNj14ew8cKjSX4JNhg=; b=b6+t2HcFUu+dYO48LIVhhUEWm5L3KdKoFHxF5pXQwCJ9Q6qsKAGzUHa3x12R7+fqL3 UsC37PJYvq8ZLRS7m7zX3X9jPbJ9yr8J3nUb2e9G1r4c/IzRQlmkrp7xN8XMH+gJy4+e w3xbRCLrSXgMPQuv9T8F2m/6SYnk/988JSpvySPsgoA35Mm0aPtyJjmAG0ErQ+73rap2 +QvxKHcXst9rRg3EUOga3MHxqBcaY/l7AkuM2oKkiJPSkgQmGlq61gOwWOOA/cNjBOT5 DDKfvZDkVY5Ac68ppOo1JXWiYwJytoQc/Xm+C5GwWTMI6N0vrNK50dOIcx4K35vHkg9G 6OCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=q+KjCMZrTzz8REx2zaFd0hkyHnNj14ew8cKjSX4JNhg=; b=UX2tPdOlPScroxrUcJDd+0pkoUFPffZTDRs6W+dakJYbEo9WuRpdk2WGOQqd8JlHCv dWdxX7xkxpvOvxbszaDSoFlp5LspSogGueIdQZfBL0vtqKweMuOK+VcUqj8zZPEQ+vmI zscohlktztiPuFtzu/LJxi11jby1qu34j3R98= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=q+KjCMZrTzz8REx2zaFd0hkyHnNj14ew8cKjSX4JNhg=; b=qLkAjhBPPALxxF5PEAAva/ih6ZCrSOrjLKcJeTVbCM7GRaaqDrzdu8Z5yU7bJbnWn5 kl+jtJdRGIFakPZ/pixBuTwCfcc6OUzEu/NNNoOyJUpsEj59l+7fGHgHjn4/LtvsjNub YI16JT0uLkOMAzrpLwcbCkBFDQKyF1aju9DV8GyVDZzy4+2REaTajDvWsd99AbbumADN HOXnQv8RG+HApseiqeApHU+5SrO9C4S68cH4PcFdlRaq1GMkB/iRap1nnqrjQrB/NfEr KUC3vD9SrbUJAzWwfLp/Fo0Ji/wO8Cr5b00Rp7ILTGFC9SsySdXRS2DO0ypRvvKpGpgG wdbQ== X-Gm-Message-State: AKS2vOxCYCS4fPluZDXHgixONYZc9ugdcs/id3+jIud6clFboWlf48mJ srenvs1Oxksd/SUh/+dLfxBWrqZNsP9A/MY= X-Received: by 10.223.171.3 with SMTP id q3mr41584489wrc.12.1499382087815; Thu, 06 Jul 2017 16:01:27 -0700 (PDT) MIME-Version: 1.0 Sender: jyasskin@google.com Received: by 10.28.97.6 with HTTP; Thu, 6 Jul 2017 16:01:06 -0700 (PDT) From: Jeffrey Yasskin Date: Thu, 6 Jul 2017 16:01:06 -0700 X-Google-Sender-Auth: ZQ0GzNRqyssKz_JcynsC6eb_dPk Message-ID: To: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cbor] CDDL spec should specify how CBOR items match types 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, 06 Jul 2017 23:01:32 -0000 Apologies if I'm just reading https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 badly, but I don't see a specification of which CBOR items match which types. Sections like https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11#section-3.4 (Arrays) specify how to write an array type, but I don't see a normative statement that '82 01 02' is an instance of [*uint] or that '01' and '42 01 02' aren't. I also don't see a definition of '#' in order to ground the meaning of the prelude. "How this is used should be evident from the prelude (Appendix E)." from 2.2.3. Representation Types isn't really sufficient to specify it. I think this lack of specification is at the root of Kevin Braun's set of bugs in https://mailarchive.ietf.org/arch/msg/cbor/Z1XcZSTLbTDnqA9HP8UXjeUOspE. I'd be inclined to fix this by specifying each CDDL type as a recursive parser, which accepts or rejects either CBOR items or byte strings. I think the choice of item vs bytes comes down to where we want to put the serialization constraints (like "indefinite-containers") described in https://mailarchive.ietf.org/arch/msg/cbor/Pv191TJRBiG1QOJbJL8iVHjUDuE, but it could also have some implications for how parsers return data from unfinished byte streams. Jeffrey From nobody Thu Jul 6 23:44:18 2017 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 068D612F257 for ; Thu, 6 Jul 2017 23:44:17 -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 iRAlbcCiUSfx for ; Thu, 6 Jul 2017 23:44:15 -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 EE1C0128B8F for ; Thu, 6 Jul 2017 23:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v676iB8o018681; Fri, 7 Jul 2017 08:44:11 +0200 (CEST) Received: from [192.168.217.124] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x3lSq0nMdz3ZF6; Fri, 7 Jul 2017 08:44:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Jul 2017 08:44:10 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 521102650.332144-d7e10745bf9e8fde2f9e0593a09df220 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cbor] CDDL spec should specify how CBOR items match types 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: Fri, 07 Jul 2017 06:44:17 -0000 Hi Jeffrey, Yes, we have to replace =E2=80=9Cself-evident=E2=80=9D etc. by actually = explaining things. However, I=E2=80=99m pretty sure we are on the safe side with the # = constructs, as well as with [] and {}. These may not be explained in so many words, but it is still pretty = clear what they mean. We have more of an undefined state with literals such as 10, 10.0, 1e1, = and with applying range operators, in particular if they span CBOR major = types (-5..10 is pretty clear, but what does 1..10.0 mean?). When = applied to floating point, the range operator also does not say what = precision is needed (you can help yourself with construct such as = `-10.0..10.0 .and float16`, but that is neither supported by the tool = nor explained at all). I would like to keep CDDL operating at the data model level, even with = its history of toying with anchoring it at the serialization level. = Yes, the # construct is in serialization terms, but this is just a = shortcut to have a single construct cover all of CBOR (well, you have to = add {} and [], because these need groups). There are a few more areas that are not fully defined, e.g., which exact = PCRE variant exactly does .regexp use. I would be inclined in *not* overspecifying this at this point. (And we = haven=E2=80=99t solved the =E2=80=9Cline too long=E2=80=9D problem = there; see prelude for tdate which is not using a regexp even though it = could =E2=80=94 try a `cddl -<< On Jul 7, 2017, at 01:01, Jeffrey Yasskin = wrote: >=20 > Apologies if I'm just reading > https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 > badly, but I don't see a specification of which CBOR items match which > types. >=20 > Sections like = https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11#sectio= n-3.4 > (Arrays) specify how to write an array type, but I don't see a > normative statement that '82 01 02' is an instance of [*uint] or that > '01' and '42 01 02' aren't. >=20 > I also don't see a definition of '#' in order to ground the meaning of > the prelude. "How this is used should be evident from the prelude > (Appendix E)." from 2.2.3. Representation Types isn't really > sufficient to specify it. >=20 > I think this lack of specification is at the root of Kevin Braun's set > of bugs in = https://mailarchive.ietf.org/arch/msg/cbor/Z1XcZSTLbTDnqA9HP8UXjeUOspE. >=20 > I'd be inclined to fix this by specifying each CDDL type as a > recursive parser, which accepts or rejects either CBOR items or byte > strings. I think the choice of item vs bytes comes down to where we > want to put the serialization constraints (like > "indefinite-containers") described in > = https://mailarchive.ietf.org/arch/msg/cbor/Pv191TJRBiG1QOJbJL8iVHjUDuE, > but it could also have some implications for how parsers return data > from unfinished byte streams. >=20 > Jeffrey >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 From nobody Fri Jul 7 08:01:10 2017 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 2C02813160A for ; Fri, 7 Jul 2017 08:01:08 -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, RP_MATCHES_RCVD=-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 cg2l3gX3WTt7 for ; Fri, 7 Jul 2017 08:01:05 -0700 (PDT) Received: from server.obj-sys.com (server.obj-sys.com [74.50.121.244]) (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 6F9FF13161A for ; Fri, 7 Jul 2017 08:01:05 -0700 (PDT) Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:62289 helo=[10.0.0.100]) by server.obj-sys.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dTUkg-0004V9-Aj; Fri, 07 Jul 2017 11:01:02 -0400 To: Carsten Bormann Cc: cbor@ietf.org References: <6870432F-AB25-4F58-B377-9B163A303D87@tzi.org> From: Kevin Braun Message-ID: <789cfd85-b765-306f-57d7-26297e5d5b55@obj-sys.com> Date: Fri, 7 Jul 2017 11:01:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6870432F-AB25-4F58-B377-9B163A303D87@tzi.org> Content-Type: multipart/alternative; boundary="------------45E61B3623658E9BABA036CD" Content-Language: en-US X-Antivirus: Avast (VPS 170707-0, 07/07/2017), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.obj-sys.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - obj-sys.com X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: kbraun@obj-sys.com X-Authenticated-Sender: server.obj-sys.com: kbraun@obj-sys.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Cbor] Some questions on CDDL 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: Fri, 07 Jul 2017 15:01:08 -0000 This is a multi-part message in MIME format. --------------45E61B3623658E9BABA036CD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/6/2017 6:15 PM, Carsten Bormann wrote: >> On Jul 6, 2017, at 23:33, Kevin Braun wrote: >> >> Hi folks, >> >> I am investigating CDDL and have several questions and comments. >> >> 1. When a value (e.g. a text string, byte string, integer, or float) appears in a rule, what does that means for the CBOR data? The document doesn't make this explicit. I experimented using the CDDL tool (0.8.5) and that didn't bring clarity. For example, this rule: >> top = { 1 => "turkey" } >> validates both of these instances: >> { 1 : "turkey" } >> { 1 : 'turkey’ } > Bug. Only the first one is valid with this description. > >> I would have thought the second instance ought to be invalid, since a byte string was found where a text string is expected, but the CDDL spec isn't decisive on this. > Do you have a suggestion what we should add to the spec? > The CBOR spec is quite clear that byte strings and text strings are not the same; we could add an example that demonstrates this with CDDL as well (e.g., your example). I wasn't sure about it due to the fact that a byte string can be written using characters and due to the behavior of the tool, plus there isn't an explicit description of how validation works. I thought if integer values can validate CBOR floats, perhaps text values can validate CBOR byte strings and vice versa. I would suggest spelling out the relation between CDDL values and what they will validate/match in CBOR. That would cover the int/float and other numerics issues too. For example, "CDDL values have corresponding CBOR representations against which they alone will match. The following table indicates the CBOR major type and (for floats) the extra information that alone can be matched for each kind of value: integer 0 or 1 byte string 2 text string 3 float 7.25 or 7.26 or 7.27 " > >> Meanwhile, using the following rule, neither of the above instances will validate: >> top = { 1 => 'turkey' } >> In both cases, the error is: >> CDDL validation failure (nil for {1=>"turkey"}): >> ["turkey", [:bytes, "turkey"], nil] > This is another expression of the same bug. > >> 2. Related to the above question, numeric handling is confusing. On the one hand, >> top = { ? "test" : [*mix-int-float] } >> mix-int-float = 1 / 2 / 10.0 >> will validate >> { "test" : [ 1, 2, 10.0, 1.0, 2.0, 10 ] } >> which suggests that a literal float can validate an integer value and vice-versa. > This is indeed an interesting question. > In a CBOR data model, ints and floats are rather different. > In a JSON data model, they nominally aren’t (although they are very much in many practical applications of JSON). > > We will need to make a few decisions here. > I would tend to go for a complete separation of integer and float, but we do need to make up our mind how JSON fits in there. (We also, in all likelihood, need conversion operators or some such. Ouch.) > >> But then, if I try defining this: >> mixed-range = 1..10.0 >> CDDL tool gives me an error: Incompatible range [Integer, Float]. For a range, integers and floats seem to be treated distinctly. I don't know whether this reflects the CDDL specification's intention or is just a limit of the tool. > Right, as with strings, the tool is a bit “simple-minded” (read: broken) with its idea of equality. > >> Also, this rule: >> top = { 1 => "turkey" } >> will not validate >> { 1.0 : "turkey" } >> which suggests that a literal integer will NOT validate a float value, contrary to how mix-int-float is handled. However, the following DOES validate the same instance: >> top = { one => "turkey" } >> one = 1 / 10.0 >> which just further muddies the waters. Again, this might all be due to limitations or bugs in the CDDL tool, but the CDDL spec doesn't make clear what should happen in these cases. > Nice demos for why I’m in the process of rewriting parts of the tool at this very moment… > The current tool essentially exposes idiosyncrasies of the data model of the programming language it is written in; instead, it needs to be based on the more explicit choices we make. > >> 3. CDDL tool reports an error if you try to use an mapentry without a key inside a map, such as in: >> top= {mygroup, secondgroup} >> mygroup = ("thing-one" : uint, "thing-two" : tstr) >> secondgroup = (uint, tstr) >> This is sensible, but I don't think the specification actually forbids this; perhaps it should. > Yes, the spec should say that a group needs member keys in order to be used in a map. > >> 4. When a map has duplicate keys, CDDL tool will generate data using the last definition of the key. I didn't find an instance it would validate, though. Perhaps the specification should require an error in such cases. Example: >> top = { "thing" : uint, "thing" : tstr } >> Generated value: >> {h'7468696E67': "tic”} > Another tool bug. First, the member key should not transmogrify into a byte string. > > The CDDL spec is bad in that it can never be satisfied. It is not really “wrong” in any other way, and it might be hard to detect this particular error in a more general case. > > The tool has a bug here in that it enters a key into the map without checking whether it was present already. > >> 5. CDDL tool reports an error (`block in grpent') when trying to generate instances for the following schema. I think it is valid CDDL and this is probably just a bug in the tool: >> top = { topgroup } >> >> topgroup = ( first: tstr, second: tstr, >> (option1: uint // >> option2: uint) ) > There is a nice “XXX” in that source line 1038 :-) > It just doesn’t know how to handle a group choice here. > (Group choices came in when the logic already was based on knowing there weren’t any and not all cases are actually implemented at this point.) > >> 6. Are there restrictions on the use of '&' to create a choice from a group? I think some sensible restrictions would be: >> - every mapentry in the group must have a key type which must be a single-value > Why do you want this restriction? > (It doesn’t hurt very much, but I also think it doesn’t help.) Well, someone could write something like: colors = &color_group color_group = ( int => 0, green: 1, blue:2) It's pretty clear that isn't how & is intended to be used, but I believe it is perfectly legal as things stand. If a tool is going to give special support for "choice from group", such as displaying the name associated with a value, it would simplify things if the tool could rely on there being a nice 1-to-1 name-value mapping. > >> - the group cannot use group choice (//) >> - the mapentry values must be unique, single-value types? > Yes. > >> At least, I think the above rules would be consistent with the intent of the "&" operator as described. >> >> 7. What happens when you have an empty group? Section 3.9 Socket/Plug would lead one to believe that an empty group cannot be matched, since it says that an undefined socket symbol is "taken to be an empty type choice (group choice)" and "It is not an error if there is no definition for a socket at all; this then means there is no way to satisfy the rule (i.e., the choice is empty)." But, the CDDL tool does not behave the same when a socket symbol is undefined and when it is defined as empty. The following instance: >> { "one" : 7, "two" : "seven" } >> is validated by: >> top = { one: uint, two: tstr, extra-junk } >> extra-junk = () >> and by: >> top = { one: uint, two: tstr, $$extra-junk } >> $$extra-junk //= () >> but not by: >> top = { one: uint, two: tstr, $$extra-junk } >> ; $$extra-junk undefined > An empty group is very different from an empty group choice. > > CDDL does not currently provide a notation for an empty group choice (which would be the bottom or “fail” symbol in a grammar), so the last test case is the only way to get one. > An empty group, however, is approximately a no-op. It can be very much a part of a group choice, besides other alternatives... > (There can’t be an empty type, as a type is always matched by exactly one data item.) Okay. My two cent's worth then - I wouldn't talk about empty types or empty choices in that section as you're introducing a concept that the rest of the specification doesn't give a meaning to. I would just say "Tools honor that convention by not raising an error if such a type or group is not defined at all; the symbol is then taken to represent a rule that cannot be satisfied." and then later on, "It is not an error if there is no definition for a socket at all; this then means there is no way to satisfy the rule." > >> The description of an undefined socket as equivalent to an empty choice seems inconsistent with the observed behavior. I don't see an inherent problem with this behavior; I just think that explaining the undefined symbol behavior in terms of an empty choice group is inaccurate and probably misleading (assuming the CDDL tool is work as desired). > See above. > > Thank you Kevin; I’ll turn most of your message into a number of failing tests for the CDDL tool (which will then hopefully be fixed by the partial reimplementation). > > The question of equality of ints and floats (and, maybe even more difficult, bignums and decimals and bigfloats) needs some thinking and appropriate spec updates. I’d love to hear more about the use case where you ran into the current implementation idiosyncrasies around these equality issues; those might help us make the right choices there. Unfortunately, I don't have a concrete use case to share. We're interested in commercial CBOR and CDDL tool development, so I'm just examining the specification and thinking about possibilities. Thanks, Kevin --------------45E61B3623658E9BABA036CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 7/6/2017 6:15 PM, Carsten Bormann wrote:

      

        
On Jul 6, 2017, at 23:33, Kevin Braun <kbraun@obj-sys.com> wrote:

Hi folks,

I am investigating CDDL and have several questions and comments.

1. When a value (e.g. a text string, byte string, integer, or float) appears in a rule, what does that means for the CBOR data?  The document doesn't make this explicit.  I experimented using the CDDL tool (0.8.5) and that didn't bring clarity.  For example, this rule:
   top = { 1 => "turkey" }
validates both of these instances:
   { 1 : "turkey" }
   { 1 : 'turkey’ }


      

      
Bug.  Only the first one is valid with this description.



      

        
I would have thought the second instance ought to be invalid, since a byte string was found where a text string is  expected, but the CDDL spec isn't decisive on this.


      

      
Do you have a suggestion what we should add to the spec?
The CBOR spec is quite clear that byte strings and text strings are not the same; we could add an example that demonstrates this with CDDL as well (e.g., your example).

    

    

    I wasn't sure about it due to the fact that a byte string can be
    written using characters and due to the behavior of the tool, plus
    there isn't an explicit description of how validation works.  I
    thought if integer values can validate CBOR floats, perhaps text
    values can validate CBOR byte strings and vice versa.  I would
    suggest spelling out the relation between CDDL values and what they
    will validate/match in CBOR.  That would cover the int/float and
    other numerics issues too.  For example, "CDDL values have
    corresponding CBOR representations against which they alone will
    match.  The following table indicates the CBOR major type and (for
    floats) the extra information that alone can be matched for each
    kind of value:

        integer             0 or 1

        byte string        2

        text string         3

        float                 7.25 or 7.26 or 7.27

    "

    

      



      

        
Meanwhile, using the following rule, neither of the above instances will validate:
   top = { 1 => 'turkey' }
In both cases, the error is:
   CDDL validation failure (nil for {1=>"turkey"}):
   ["turkey", [:bytes, "turkey"], nil]


      

      
This is another expression of the same bug.



      

        
2. Related to the above question, numeric handling is confusing.  On the one hand,
   top = { ? "test" : [*mix-int-float] }
   mix-int-float = 1 / 2 / 10.0
will validate
   { "test" : [ 1, 2, 10.0, 1.0, 2.0, 10 ] }
which suggests that a literal float can validate an integer value and vice-versa.  


      

      
This is indeed an interesting question.
In a CBOR data model, ints and floats are rather different.
In a JSON data model, they nominally aren’t (although they are very much in many practical applications of JSON).

We will need to make a few decisions here.
I would tend to go for a complete separation of integer and float, but we do need to make up our mind how JSON fits in there.  (We also, in all likelihood, need conversion operators or some such.  Ouch.)



      

        
But then, if I try defining this:
   mixed-range = 1..10.0
CDDL tool gives me an error: Incompatible range [Integer, Float]. For a range, integers and floats seem to be treated distinctly.  I don't know whether this reflects the CDDL specification's intention or is just a limit of the tool.


      

      
Right, as with strings, the tool is a bit “simple-minded” (read: broken) with its idea of equality.



      

        
Also, this rule:
   top = { 1 => "turkey" }
will not validate
   { 1.0 : "turkey" }
which suggests that a literal integer will NOT validate a float value, contrary to how mix-int-float is handled.  However, the following DOES validate the same instance:
   top = { one => "turkey" }
   one = 1 / 10.0
which just further muddies the waters.  Again, this might all be due to limitations or bugs in the CDDL tool, but the CDDL spec doesn't make clear what should happen in these cases.


      

      
Nice demos for why I’m in the process of rewriting parts of the tool at this very moment…
The current tool essentially exposes idiosyncrasies of the data model of the programming language it is written in; instead, it needs to be based on the more explicit choices we make.



      

        
3. CDDL tool reports an error if you try to use an mapentry without a key inside a map, such as in:
   top= {mygroup, secondgroup}
   mygroup = ("thing-one" : uint, "thing-two" : tstr)
   secondgroup = (uint, tstr)
This is sensible, but I don't think the specification actually forbids this; perhaps it should.


      

      
Yes, the spec should say that a group needs member keys in order to be used in a map.



      

        
4. When a map has duplicate keys, CDDL tool will generate data using the last definition of the key.  I didn't find an instance it would validate, though.  Perhaps the specification should require an error in such cases.  Example:
   top = { "thing" : uint, "thing" : tstr }
Generated value:
   {h'7468696E67': "tic”}


      

      
Another tool bug.  First, the member key should not transmogrify into a byte string.

The CDDL spec is bad in that it can never be satisfied.  It is not really “wrong” in any other way, and it might be hard to detect this particular error in a more general case.

The tool has a bug here in that it enters a key into the map without checking whether it was present already.



      

        
5. CDDL tool reports an error (`block in grpent') when trying to generate instances for the following schema.  I think it is valid CDDL and this is probably just a bug in the tool:
   top = { topgroup }

   topgroup = ( first: tstr, second: tstr,
            (option1: uint //
            option2: uint) )


      

      
There is a nice “XXX” in that source line 1038 :-)
It just doesn’t know how to handle a group choice here.
(Group choices came in when the logic already was based on knowing there weren’t any and not all cases are actually implemented at this point.)



      

        
6. Are there restrictions on the use of '&' to create a choice from a group?  I think some sensible restrictions would be:
- every mapentry in the group must have a key type which must be a single-value


      

      
Why do you want this restriction?
(It doesn’t hurt very much, but I also think it doesn’t help.)

    

    

    Well, someone could write something like:

    
	colors = &color_group
	color_group = ( int => 0, green: 1, blue:2)


    It's pretty clear that isn't how & is intended to be used, but I
    believe it is perfectly legal as things stand.  If a tool is going
    to give special support for "choice from group", such as displaying
    the name associated with a value, it would simplify things if the
    tool could rely on there being a nice 1-to-1 name-value mapping.

    

    

      



      

        
- the group cannot use group choice (//)
- the mapentry values must be unique, single-value types?


      

      
Yes.



      

        
At least, I think the above rules would be consistent with the intent of the "&" operator as described.

7. What happens when you have an empty group?  Section 3.9 Socket/Plug would lead one to believe that an empty group cannot be matched, since it says that an undefined socket symbol is "taken to be an empty type choice (group choice)" and "It is not an error if there is no definition for a socket at all; this then means there is no way to satisfy the rule (i.e., the choice is empty)."  But, the CDDL tool does not behave the same when a socket symbol is undefined and when it is defined as empty.  The following instance:
   { "one" : 7, "two" : "seven" }
is validated by:
   top = { one: uint, two: tstr, extra-junk }
   extra-junk = ()
and by:
   top = { one: uint, two: tstr, $$extra-junk }
   $$extra-junk //= ()
but not by:
   top = { one: uint, two: tstr, $$extra-junk }
   ; $$extra-junk undefined


      

      
An empty group is very different from an empty group choice.

CDDL does not currently provide a notation for an empty group choice (which would be the bottom or “fail” symbol in a grammar), so the last test case is the only way to get one.
An empty group, however, is approximately a no-op.  It can be very much a part of a group choice, besides other alternatives...
(There can’t be an empty type, as a type is always matched by exactly one data item.)

    

    

    Okay.  My two cent's worth then - I wouldn't talk about empty types
    or empty choices in that section as you're introducing a concept
    that the rest of the specification doesn't give a meaning to.  I
    would just say "Tools honor that convention by not raising an error
    if such a type or group is not defined at all; the symbol is then
    taken to represent a rule that cannot be satisfied."  and then later
    on, "It is not an error if there is no definition for a socket at
    all; this then means there is no way to satisfy the rule."

    

    

      



      

        
The description of an undefined socket as equivalent to an empty choice seems inconsistent with the observed behavior.  I don't see an inherent problem with this behavior; I just think that explaining the undefined symbol behavior in terms of an empty choice group is inaccurate and probably misleading (assuming the CDDL tool is work as desired).


      

      
See above.

Thank you Kevin; I’ll turn most of your message into a number of failing tests for the CDDL tool (which will then hopefully be fixed by the partial reimplementation).

The question of equality of ints and floats (and, maybe even more difficult, bignums and decimals and bigfloats) needs some thinking and appropriate spec updates.  I’d love to hear more about the use case where you ran into the current implementation idiosyncrasies around these equality issues; those might help us make the right choices there.

    

    

    Unfortunately, I don't have a concrete use case to share.  We're
    interested in commercial CBOR and CDDL tool development, so I'm just
    examining the specification and thinking about possibilities.

    

    Thanks,

    Kevin

  


--------------45E61B3623658E9BABA036CD--


From nobody Sun Jul  9 07:36:32 2017
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 9B59A131548 for ; Sun,  9 Jul 2017 07:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=f6O33+cj; dkim=pass (1024-bit key) header.d=chromium.org header.b=lHrOpOwk
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 O_aK5skFirOu for ; Sun,  9 Jul 2017 07:36:29 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A80131472 for ; Sun,  9 Jul 2017 07:36:28 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id r103so106293771wrb.0 for ; Sun, 09 Jul 2017 07:36:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=6Y22YA5CVcasd7hBstqNe4yeTl7hO1HnmAXvIgaaBHg=; b=f6O33+cjo2FsycOLsiLgvKBgsvRonIv4Dq7FsHQKWxNLjjNldXsm2ydHIB7BBIQX1B y4n2i/tMd1PH3f43Px0XlTdZ/PdADRYf+pRtAaUc+oC2N+XmN1Pj73u+Qx/uhw7qyo0q UuNJ9CuN1znvdit+0DtDZuXLCZZ161RTo2Q0MLgDI5cVwRiw6Mjt/vblJgnOuEk9aILC fLQ6VORx8vCyA61XM0txW6qJRjlFszhDIMBmvTQIlCxxjZW82z1lmkpExBo/eEG6l3Ks 8SgUqXxg2K056Qu+6+OL2TfOiqa1jL8fFVNqoc5V6DYtAzvKazcR121pJD36BZQKJld5 7Pzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=6Y22YA5CVcasd7hBstqNe4yeTl7hO1HnmAXvIgaaBHg=; b=lHrOpOwkanIU1SQzXQlAFboQuGFG3f1gKuxPDDYrz1WCkhPh7vJQM+M0jXt4A+20e+ oukLW4bZloAcsQXV0hqu3FXcacoS0xEFX/jiM7iH35VFOU+/YHsh6QilBtALEBUfXO3+ Ji/tqZDylAADZfeXp1uU0wRO6cv3nr4+s6T0I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=6Y22YA5CVcasd7hBstqNe4yeTl7hO1HnmAXvIgaaBHg=; b=bL7cPfz6mIpZ1J2cvEg2vhfNnVHEpR3hbJ4N1fOxoC+eHKIRuGGNE6EnTWuW27ySHV 2JMc/1iQaBgBPRJUMLQhkAtpm9mu4YbLboE2TW7LINFuz/HUcLcs+2z4JkThU3HjPslO LjlF8LWtPkQ6u00DbrurBr6HwlSY+wfXGWtgeajShxL2h0jkDwlC3zpaUagzhA+JXhoa WUu0cF1LumxqcQbLfwaBr9xYQzwEaMPFZarGhLl2tI1d/+Uyx4A5TSbwJcHFLd+xL11/ e5TtQlcB7jrUDsnVqvRcVUMIENYhre0SZLO782NSROLTFRoRaD6aBhOTtjoJFBW1/NI8 Z4rw==
X-Gm-Message-State: AIVw110HbYJmO8aVJUO+pAW/PlM7XJnywxrBBAoLMKIy6NMvM5kPdxwI Gx8rgaEa9faT3ydO88u4mp5Q6c2D7y8N
X-Received: by 10.223.175.37 with SMTP id z34mr4977228wrc.11.1499610987111; Sun, 09 Jul 2017 07:36:27 -0700 (PDT)
MIME-Version: 1.0
Sender: jyasskin@google.com
Received: by 10.28.97.6 with HTTP; Sun, 9 Jul 2017 07:36:06 -0700 (PDT)
In-Reply-To: 
References: 
From: Jeffrey Yasskin 
Date: Sun, 9 Jul 2017 07:36:06 -0700
X-Google-Sender-Auth: GVWO7neiHKkAavPPMo_DqKxWavU
Message-ID: 
To: Francesca Palombini 
Cc: "cbor@ietf.org" , "cbor-chairs@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_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 14:36:31 -0000

The Chicago minutes [1] talk about people using CDDL to write
specifications, but the -11 document is on the informational track
rather than the standards track, meaning, I believe, that it's not
intended to be referenced normatively from specifications. If folks do
want to be able to use CDDL from standards, would the draft need to
change tracks before it becomes a working group item?

If it can change tracks later, then I definitely support adopting it
as a starting point. If adopting it freezes it as informational, then
I'm concerned, however much that counts from a newbie. :)

Thanks,
Jeffrey

[1]: https://mailarchive.ietf.org/arch/msg/cbor/HrfvEralF6mjmO4uK7ZZrz7n7uE=
/?qid=3D5a4cfef2594f32f86b5eea519fbbabd0


On Wed, Jul 5, 2017 at 2:48 AM, Francesca Palombini
 wrote:
> Hi all,
>
>
>
> At the IETF98 meeting, we had in-room consensus to adopt
> draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR
> data definition language. The authors have now updated the document and f=
eel
> this is ready to be a wg item.
>
>
>
> This is a confirmation call for adopting this draft as a working group it=
em.
> If you do not agree with the in-room consensus that we had in Chicago to
> adopt this as a WG document, please speak up until 2017-07-19. If you
> weren=E2=80=99t in the room but do agree with adopting this document, you=
 can also
> tell us.
>
>
>
> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11
>
>
>
> Thanks,
>
> Francesca
>
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>


From nobody Sun Jul  9 07:45:22 2017
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 878E11293E1 for ; Sun,  9 Jul 2017 07:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=OC2cGOFC; dkim=pass (1024-bit key) header.d=chromium.org header.b=l+6tfrRJ
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 y8z7lSR1Kv00 for ; Sun,  9 Jul 2017 07:45:19 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E0C128990 for ; Sun,  9 Jul 2017 07:45:19 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id c11so106299467wrc.3 for ; Sun, 09 Jul 2017 07:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=rMpF6hkSQLQUzYjzdVf9Ra0DKEl3RBQ96vjOXCAwnJg=; b=OC2cGOFCVFQzd2/d1yzCCDe4VQ7a/X54Vshr+2M+3oQhztOQ80alYehLvOfxKuONt6 ALBNKNSlHzvZ92ypr4hs3IpG27GgZ1lDyRj4Ju9Pb3wB/SGm28/gL9Z4h+9C/yzMjv+y EU8aLk/drE58fkHhJ6Bcsu4iwxw/gUjor23BORrvoB7ujlJ0TuWLQb2Ji0A/KupeD7EW BBvpcuVycHJnzYG1s0eEyQlc5BxMGGV4CxtjbMwEyqACybrK+tNAU8XegIV9oJ9rRB6i BkfbEBEc1neefMLO0lx9VB+u2PEuQm5rmqYAKB9yQytZi+Tk6AduM2to/Z+yEMuvZk6w PayA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=rMpF6hkSQLQUzYjzdVf9Ra0DKEl3RBQ96vjOXCAwnJg=; b=l+6tfrRJE1W9/qWv2T9ZxHhwyJh0luPFjM3LdaRh3+GMWRo4n4zlZDSqWmhfEXMNNd 0l9P8M90qRHK5F8Qugy5RIZ7cD5bSaQ/RPleiQi2nQPwWIEIF3FWii+aUowepjCZhqcB hw1sB7kRmP/amXFW/Qe7Ut2MPidhpZRYUZKL8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=rMpF6hkSQLQUzYjzdVf9Ra0DKEl3RBQ96vjOXCAwnJg=; b=iElng9/zXyM4KqDyx/EQEzVxf9ZO5I3vm4AYl7UKWMi0i/QDhTGkXXdB08c/0Bw301 NrLkVR1Bghf/TztrzS/yQ2BoBhIbQEhpgxz3tBabwacI38C7KJU5qMC+PaDQqcSP0YtY 7jQkJRsOpc4KbG7geeI+HOeQ3YbQMIA6Xx9+hDAbq3jU3IHW0Ac50rDDR8iTyvM+t+MO LGPqckHJGJvTDaaDTI85DAhFQDwIHggjHZ2Xe5IlvE7EaA7NTC7y89kvOi6bjimpbwnR w5sy7x3SQXD4JlAImKJcKZwn0vnZpi92AzG8JBeEK0Mgk6/XWSy4bTUw+io3aHK+kUcF VA1w==
X-Gm-Message-State: AIVw113mPzXPr8prXrdnqjfg2Uc8Wnx/OWfl0zZOqgSX3NgJGfdJnJDV RUFvnCfN29oOG1X4RulcE5lUDvKs/Y9NNbKW2w==
X-Received: by 10.223.183.40 with SMTP id l40mr5647314wre.154.1499611517857; Sun, 09 Jul 2017 07:45:17 -0700 (PDT)
MIME-Version: 1.0
Sender: jyasskin@google.com
Received: by 10.28.97.6 with HTTP; Sun, 9 Jul 2017 07:44:57 -0700 (PDT)
In-Reply-To: 
References:  
From: Jeffrey Yasskin 
Date: Sun, 9 Jul 2017 07:44:57 -0700
X-Google-Sender-Auth: iIJAO_xzAG7wcXLfSzMtFQPUHkg
Message-ID: 
To: Carsten Bormann 
Cc: Jeffrey Yasskin , cbor@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor] CDDL spec should specify how CBOR items match types
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: Sun, 09 Jul 2017 14:45:21 -0000

I just noticed that the current draft is informational, so it can't be
used the way ABNF is used, to help with writing other standards, as
much as I'd like to. For informational documents, I agree that "pretty
clear" is enough, but I hope we can aim for a standard instead.

Jeffrey

On Thu, Jul 6, 2017 at 11:44 PM, Carsten Bormann  wrote:
> Hi Jeffrey,
>
> Yes, we have to replace =E2=80=9Cself-evident=E2=80=9D etc. by actually e=
xplaining things.
>
> However, I=E2=80=99m pretty sure we are on the safe side with the # const=
ructs, as well as with [] and {}.
> These may not be explained in so many words, but it is still pretty clear=
 what they mean.
>
> We have more of an undefined state with literals such as 10, 10.0, 1e1, a=
nd with applying range operators, in particular if they span CBOR major typ=
es (-5..10 is pretty clear, but what does 1..10.0 mean?).  When applied to =
floating point, the range operator also does not say what precision is need=
ed (you can help yourself with construct such as `-10.0..10.0 .and float16`=
, but that is neither supported by the tool nor explained at all).
>
> I would like to keep CDDL operating at the data model level, even with it=
s history of toying with anchoring it at the serialization level.  Yes, the=
 # construct is in serialization terms, but this is just a shortcut to have=
 a single construct cover all of CBOR (well, you have to add {} and [], bec=
ause these need groups).
>
> There are a few more areas that are not fully defined, e.g., which exact =
PCRE variant exactly does .regexp use.
> I would be inclined in *not* overspecifying this at this point.  (And we =
haven=E2=80=99t solved the =E2=80=9Cline too long=E2=80=9D problem there; s=
ee prelude for tdate which is not using a regexp even though it could =E2=
=80=94 try a `cddl -<<
> So, lots of editorial work remaining indeed, but the technical discussion=
 probably should focus on the numeric system underlying CDDL.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
>> On Jul 7, 2017, at 01:01, Jeffrey Yasskin  wrote:
>>
>> Apologies if I'm just reading
>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11
>> badly, but I don't see a specification of which CBOR items match which
>> types.
>>
>> Sections like https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbo=
r-cddl-11#section-3.4
>> (Arrays) specify how to write an array type, but I don't see a
>> normative statement that '82 01 02' is an instance of [*uint] or that
>> '01' and '42 01 02' aren't.
>>
>> I also don't see a definition of '#' in order to ground the meaning of
>> the prelude. "How this is used should be evident from the prelude
>> (Appendix E)." from 2.2.3. Representation Types isn't really
>> sufficient to specify it.
>>
>> I think this lack of specification is at the root of Kevin Braun's set
>> of bugs in https://mailarchive.ietf.org/arch/msg/cbor/Z1XcZSTLbTDnqA9HP8=
UXjeUOspE.
>>
>> I'd be inclined to fix this by specifying each CDDL type as a
>> recursive parser, which accepts or rejects either CBOR items or byte
>> strings. I think the choice of item vs bytes comes down to where we
>> want to put the serialization constraints (like
>> "indefinite-containers") described in
>> https://mailarchive.ietf.org/arch/msg/cbor/Pv191TJRBiG1QOJbJL8iVHjUDuE,
>> but it could also have some implications for how parsers return data
>> from unfinished byte streams.
>>
>> Jeffrey
>>
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>>
>


From nobody Sun Jul  9 08:46:39 2017
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 92A4912EA7C for ; Sun,  9 Jul 2017 08:46: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 n7xmw5eW11iE for ; Sun,  9 Jul 2017 08:46:33 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56F9129B4C for ; Sun,  9 Jul 2017 08:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v69FkTZg011872; Sun, 9 Jul 2017 17:46:29 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x5CPc6J2Wz3Zmw; Sun,  9 Jul 2017 17:46:28 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 9 Jul 2017 17:46:28 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 521307988.072546-6548204e6105b3763db680187b487e77
Content-Transfer-Encoding: quoted-printable
Message-Id: <258C92B3-8988-437E-A7D8-65B8B913668C@tzi.org>
References:   
To: Jeffrey Yasskin 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] CDDL spec should specify how CBOR items match types
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: Sun, 09 Jul 2017 15:46:38 -0000

On Jul 9, 2017, at 16:44, Jeffrey Yasskin  wrote:
>=20
> I just noticed that the current draft is informational, so it can't be
> used the way ABNF is used, to help with writing other standards, as
> much as I'd like to. For informational documents, I agree that "pretty
> clear" is enough, but I hope we can aim for a standard instead.

Informational was where this was started as an individual effort.
Now that we have a WG, we can go beyond that.

https://datatracker.ietf.org/doc/charter-ietf-cbor/ says:

   The CBOR WG will complete the development
   of this specification by creating an Informational or Standards Track
   RFC.

So the WG has a choice here.

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


From nobody Sun Jul  9 09:03:18 2017
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 2D881127077; Sun,  9 Jul 2017 09:03:17 -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 Cl8yo0OBwG4q; Sun,  9 Jul 2017 09:03:15 -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 19B20129B5B; Sun,  9 Jul 2017 09:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v69G39pK026061; Sun, 9 Jul 2017 18:03:09 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x5Cms1k4Zz3Zn1; Sun,  9 Jul 2017 18:03:09 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 9 Jul 2017 18:03:08 +0200
Cc: Francesca Palombini , "cbor@ietf.org" , "cbor-chairs@ietf.org" 
X-Mao-Original-Outgoing-Id: 521308988.381981-c97f13d1c00607a8a316f5968681a912
Content-Transfer-Encoding: quoted-printable
Message-Id: <428A8258-7A12-4BCD-A9B1-414EA751F4B5@tzi.org>
References:  
To: Jeffrey Yasskin 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 16:03:17 -0000

On Jul 9, 2017, at 16:36, Jeffrey Yasskin  wrote:
>=20
> If folks do
> want to be able to use CDDL from standards, would the draft need to
> change tracks before it becomes a working group item?

Yes.  That is not unusual; documents often change the track even when =
they already are in IESG processing.

> If it can change tracks later, then I definitely support adopting it
> as a starting point. If adopting it freezes it as informational, then
> I'm concerned, however much that counts from a newbie. :)

I don=E2=80=99t think the WG has to make the choice (that I talked about =
the in the previous message) now with adoption.  On the other hand, the =
purpose of this work is to make the CDDL document a referenceable =
specification language specification.  For ABNF, this was solved by =
making the spec language spec itself standards track (starting with RFC =
2234 in November 1997, after ABNF had been in use for two decades (*)).  =
Putting out an informational document on the downref list (**) is more =
circuitous, but would have the same effect. =20

(I would prefer to use RFC 2234/4234/5234 as a model here as much as =
possible, maybe with the exception of waiting 20 years before =
standardizing :-).)

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

(*) Starting with RFC 733 in November 1977, I think; although older BNF =
variants had been in use since 1968 (RFC 31).=20
(**) https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry


From nobody Sun Jul  9 13:11:28 2017
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 C9B22129B3A for ; Sun,  9 Jul 2017 13:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC0tMHwAwowU for ; Sun,  9 Jul 2017 13:11:25 -0700 (PDT)
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 1E8421270B4 for ; Sun,  9 Jul 2017 13:11:25 -0700 (PDT)
Received: from sandelman.ca (unknown [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D4DF205CB; Sun,  9 Jul 2017 16:11:53 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 153258007E; Sun,  9 Jul 2017 16:11:04 -0400 (EDT)
From: Michael Richardson 
To: "cbor\@ietf.org" 
cc: Francesca Palombini , Jeffrey Yasskin 
In-Reply-To: 
References:  
X-Mailer: MH-E 8.6; nmh 1.6+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: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 20:11:27 -0000

--=-=-=
Content-Type: text/plain


Jeffrey Yasskin  wrote:
    > The Chicago minutes [1] talk about people using CDDL to write
    > specifications, but the -11 document is on the informational track
    > rather than the standards track, meaning, I believe, that it's not
    > intended to be referenced normatively from specifications. If folks do
    > want to be able to use CDDL from standards, would the draft need to
    > change tracks before it becomes a working group item?

I didn't think that CDDL would always require a normative reference from a
standards track document.

My feeling is that if the structures are relatively simple that the CDDL is
self-describing.  Most readers and implementers won't need to go further.

I guess the question is what happens when more advanced constructs are
needed.  In that case, I guess a normative reference would be required,
and then the question would indeed arise.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllijdcACgkQgItw+93Q
3WWP9Af/ebPR9T+UH+XUuC8+LYrqBB7ryAybaMEuKlE+X/yMs1rs1lwCShaxz76+
9pr/69ecP9U6mwnXljSHOicJqNARcWMjbR0eYAQSEbB1+vrX1n31Fl65xp9t0P9d
+m+meYnZ2PotY6baCYHURAgi7J/8HWFS0LTEWeX98ZHT5UL9M2g7SDuBkwApIfmW
fYsuM0MXut+Cq0/NWMa8Hg3uEN6quRRXN9lX53eDSSeeeisqerfGLv9ezToKrLe7
We9cshnktM8yF1EVI9da6TwAP/LtXt80LNbFHo90aEJjgtlQcunQ+M5XpXtvTvO5
EcquQZQLhfytD2zfHQspTWp93Mc+RQ==
=YArr
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sun Jul  9 13:37:18 2017
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 00E5312ECB3 for ; Sun,  9 Jul 2017 13:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8LtrE4AeMa8 for ; Sun,  9 Jul 2017 13:37:15 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5373A129482 for ; Sun,  9 Jul 2017 13:37:15 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id c73so39762940pfk.2 for ; Sun, 09 Jul 2017 13:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nQcrQZ2IhGSj7voj9xqCo7jAoB37J9XZwSnT8s1L7qM=; b=CL43TafdfYpDE7qir5/4XCh95J6/e7Stu8nFrjP0ocrLHjxQHkI1dY0mSKWQP2RKJO wU15qfkbwTYyggxok0khcJrQw2ITqe/U0UzmtmKMtdMipe+rZiaQZ2uqNnlVb+ethglz IOJvXRF6IqggRcUZ+ZNt+V5eiIqtGr1OnZbOKuDidx26/rgdWrlDUNj8cMPoGRH4BX1A upiVIGsfE303pj28igkNlxDJWq14kswFuGdcKVHSui2xe6NxHPSS3E7gik5PKqxAwG6d +qyX4eb1Qpy/Ba8psBcQucH926Jo6e+NTh/LMA8bEuf5LAJ5L4hlzUXfCFv+/HgCs2qw FDcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nQcrQZ2IhGSj7voj9xqCo7jAoB37J9XZwSnT8s1L7qM=; b=NvryeOYM28jFqZEyGWCXtRTWbUGOWdNxWBDIhV3LPikx/lStWAL6rQnYOeH4fbximH VVrxIJ+JT5YOA5NiyNGDXiCitNVdzvJLNtDDbD3prmao3/Ocf7fU7dOr7HEFRlfBViGS M9lHtk6uIOEYyTIKR2O0o+5A8Wap/O/WlgmWYibODobAtEJW4Y2klzzqKReaEGoWWEgC TbTGrOxHwOUsvzAClhpx7e3EmyYXt6zacQzjaOGOMppA8VjT3VBJsPTePaovB/uPM7zo jeoc9Oly3lvyEQvHcTeqpRYUun5vwfCSchOl3x6PghKtjd3Ge09po35iJDZwwBWHIIKs 5lcw==
X-Gm-Message-State: AIVw110f6vCpjUf4YelofdBdLS51N7+vU+4cudE7peRtgrgKFUq0iUD0 9di9yQjJR6MJWafy
X-Received: by 10.84.238.206 with SMTP id l14mr14162781pln.280.1499632634511;  Sun, 09 Jul 2017 13:37:14 -0700 (PDT)
Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id i186sm19694726pgd.55.2017.07.09.13.37.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 13:37:13 -0700 (PDT)
To: Carsten Bormann , Jeffrey Yasskin 
Cc: cbor@ietf.org
References:    <258C92B3-8988-437E-A7D8-65B8B913668C@tzi.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <9eb07cab-7ea4-01eb-2919-1382b8bc72be@gmail.com>
Date: Mon, 10 Jul 2017 08:37:08 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <258C92B3-8988-437E-A7D8-65B8B913668C@tzi.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor] CDDL spec should specify how CBOR items match types
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: Sun, 09 Jul 2017 20:37:17 -0000

On 10/07/2017 03:46, Carsten Bormann wrote:
> On Jul 9, 2017, at 16:44, Jeffrey Yasskin  wrote=
:
>>
>> I just noticed that the current draft is informational, so it can't be=

>> used the way ABNF is used, to help with writing other standards, as
>> much as I'd like to. For informational documents, I agree that "pretty=

>> clear" is enough, but I hope we can aim for a standard instead.
>=20
> Informational was where this was started as an individual effort.
> Now that we have a WG, we can go beyond that.
>=20
> https://datatracker.ietf.org/doc/charter-ietf-cbor/ says:
>=20
>    The CBOR WG will complete the development
>    of this specification by creating an Informational or Standards Trac=
k
>    RFC.
>=20
> So the WG has a choice here.

IMHO we should go for Proposed Standard, even though it will be more
work to get it correct. It will make CDDL much more useful, and if it
succeeds at all it will be used as a de facto standard anyway.

This argues against inflating CDDL with new features at the moment.
We can always add features later.

Full disclosure: I have a draft very close to IESG approval that has
CDDL as a normative reference. If CDDL isn't aimed at the standards
track, I personally will have some extra work to do :-(.

    Brian

>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>=20


From nobody Sun Jul  9 13:37:52 2017
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 5469212EC15 for ; Sun,  9 Jul 2017 13:37:50 -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 M_oS_niRqEwE for ; Sun,  9 Jul 2017 13:37:48 -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 66102129482 for ; Sun,  9 Jul 2017 13:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v69KbiJk009739; Sun, 9 Jul 2017 22:37:44 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x5Ksh26hsz3Zqd; Sun,  9 Jul 2017 22:37:44 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <22969.1499631064@obiwan.sandelman.ca>
Date: Sun, 9 Jul 2017 22:37:43 +0200
Cc: "cbor@ietf.org" , Jeffrey Yasskin ,  Francesca Palombini 
X-Mao-Original-Outgoing-Id: 521325463.577712-cf32471b0355360e59edcc31c98a59c7
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <22969.1499631064@obiwan.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 20:37:50 -0000

> I didn't think that CDDL would always require a normative reference =
from a
> standards track document.
>=20
> My feeling is that if the structures are relatively simple that the =
CDDL is
> self-describing.  Most readers and implementers won't need to go =
further.

I agree with the sentiment =E2=80=94 but that=E2=80=99s not what =
happened with COSE (RFC 8152); IESG is going to insist on either =
duplicating all the normative content that uses CDDL, in another format =
(read: plain English (*)), or having a normative reference for CDDL.  I =
cannot really disagree with that from a formal point of view, so let=E2=80=
=99s make that happen.

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

(*) I seriously started writing a CDDL to =E2=80=9Cplain English=E2=80=9D =
converter, but then the situation defused a bit when the WG almost =
unanimously decided they wanted to have the CDDL in the main document.


From nobody Sun Jul  9 13:43:07 2017
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 951F812EC4B for ; Sun,  9 Jul 2017 13:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBvPfxRj_P_d for ; Sun,  9 Jul 2017 13:43:04 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E643012EC1D for ; Sun,  9 Jul 2017 13:43:03 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id t186so39495412pgb.1 for ; Sun, 09 Jul 2017 13:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ScFGyO1mrxvnEBBCLCMcxv6a7j3Wr05gZMG1F47iIiQ=; b=ZNTWJoToRHrwIxOWtsG5XiWSe+qlr3ATGfll62jPlr2Lo7F/QoT5GDBk0ZIgBYpQey dzADv0HcLcKlTZIkJaR4pWWPWReUZnRZWu+wj6q0gbuyswEX6AHgEygaDvEHklWx/Nrt F35Zqq9OTf9+oasrdzQfaALS3VwQAFDpDHHbFejhiDmEDrKiTQsZDVHtuek6Q0OxKqMf 1xyGECIYL+8sz1p/0feKkJs6DnDUOAEZ0trN1w6RWPKcEbpUbzxJb14AHXDe7k07MJ49 2HLoDmmg1rOm7Ryt2iIM/ahF85XBVr08m1aeFYYF8EUfqqwwhIRbs+xK7/wRXvqUO2Zc 1iTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ScFGyO1mrxvnEBBCLCMcxv6a7j3Wr05gZMG1F47iIiQ=; b=Aj+k/jFHARwnJNZpfjTUTv/aMPVN6bWrPFRqCXi5w7qdcciUuJDoquB5J8areJ827a l4OLkDcOrCEkPToslrelVsXdgP+Z27KOdxCHiOjYNhA4MYYl38+13H/1nDygdpI5Sque lN3zUmnmSFLHq4ul5U0cwf1cR9EbkFUS2A2my8C/QZJAtUrTkJvu0fS/vWqB+QwI7FOw ob44rndFeTTtarlu0WJFFlgyxvd0pc4s7z8Md3AD1Qu7FBIqGZj2JBcYYYrTs9FQNsw0 fxUBJh02wpYbQ38EiVpO4Ed1cnt6GuNv3MGYI1I4DBKMFzFWPoivRYA2ZYdYCYlqfrG+ WjIQ==
X-Gm-Message-State: AIVw113+9TkMZcRxitURlt5SSk9r78DMiFo59caiYaPFrdvzWBttDPRd B1LRVZ8OegsKXg==
X-Received: by 10.84.225.5 with SMTP id t5mr15127347plj.108.1499632983462; Sun, 09 Jul 2017 13:43:03 -0700 (PDT)
Received: from [192.168.178.21] ([118.148.76.144]) by smtp.gmail.com with ESMTPSA id s123sm18137048pgs.2.2017.07.09.13.43.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Jul 2017 13:43:02 -0700 (PDT)
To: Michael Richardson , "cbor@ietf.org" 
Cc: Jeffrey Yasskin , Francesca Palombini 
References:   <22969.1499631064@obiwan.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <41e610dc-bd3e-88d3-56ab-29e856b24ffd@gmail.com>
Date: Mon, 10 Jul 2017 08:42:57 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <22969.1499631064@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 20:43:06 -0000

On 10/07/2017 08:11, Michael Richardson wrote:
> 
> Jeffrey Yasskin  wrote:
>     > The Chicago minutes [1] talk about people using CDDL to write
>     > specifications, but the -11 document is on the informational track
>     > rather than the standards track, meaning, I believe, that it's not
>     > intended to be referenced normatively from specifications. If folks do
>     > want to be able to use CDDL from standards, would the draft need to
>     > change tracks before it becomes a working group item?
> 
> I didn't think that CDDL would always require a normative reference from a
> standards track document.
> 
> My feeling is that if the structures are relatively simple that the CDDL is
> self-describing.  Most readers and implementers won't need to go further.

Unfortunately I don't think that's correct. It isn't just ABNF; there are
implied semantics in the constructs. For draft-ietf-anima-grasp, this is
the draft appendix I came up with to define the subset we use:

1. CDDL is expressed in ASCII characters.
2. Data items have identifiers. An identifier is a contiguous sequence of case-sensitive letters,
   digits, underscores ("_") and hyphens ("-") starting with a letter.
3. A comment is any text starting with a semi-colon (";") until the end of the line
4. Decimal integers have their normal meaning.
5. Text strings are enclosed by double quotation '"' characters.
6. The operator "=" means that the data item on its left is defined by the expression on its right.
7. The operator "/=" means that the data item on its left MAY be defined by the expression on its right.
In an expression:
8. Parentheses ("(", ")") delimit a syntactic unit.
9. Brackets ("[", "]") delimit a CBOR array.
10. In a CBOR array, items are separated by commas (",").
11. The prefix operator "+" indicates an item that occurs at least once.
12. The prefix operator "?" indicates an item that occurs zero or more times.
13. The infix operator "/" indicates a choice.
14. The infix operator ".." indicates an inclusive range.
15. The datatype name "bytes" indicates a byte string item
16. The datatype name "text" indicates a UTF-8 character string item.
17. The datatype name "uint" indicates an unsigned integer.
18. The datatype name "any" indicates any valid CBOR item.
19. The annotation ".size" precedes the size of a data item.
20. The annotation ".bits" precedes the bit number selected in a data item.
21. The annotation ".within" indicates that the data item on its left is subsetted from the item on its right.
22. "null" means a null value.

    Brian

> 
> I guess the question is what happens when more advanced constructs are
> needed.  In that case, I guess a normative reference would be required,
> and then the question would indeed arise.
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
> 


From nobody Sun Jul  9 15:45:44 2017
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 715071200FC for ; Sun,  9 Jul 2017 15:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 9riy5p9ia0TI for ; Sun,  9 Jul 2017 15:45:40 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169B61200ED for ; Sun,  9 Jul 2017 15:45:38 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v69MjZFO006290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 10 Jul 2017 00:45:36 +0200
Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 10 Jul 2017 00:45:29 +0200
To: 
References:   <22969.1499631064@obiwan.sandelman.ca> 
From: Henk Birkholz 
Message-ID: 
Date: Mon, 10 Jul 2017 00:45:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.43.163]
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Sun, 09 Jul 2017 22:45:42 -0000

Hi all,

I have personal knowledge coming from commercial and IETF parties and 
other SDO that would like to use "CDDL instead of english" to create 
normative content and that this course of action would be "very 
appreciated" to say at the least.

I will bring this up. I cannot project the opinion of the group, but I 
am cautiously optimistic and from my personal point of view I feel 
sympathetic with the effort and will support it.

Viele Grüße,

Henk

On 07/09/2017 10:37 PM, Carsten Bormann wrote:
>> I didn't think that CDDL would always require a normative reference from a
>> standards track document.
>>
>> My feeling is that if the structures are relatively simple that the CDDL is
>> self-describing.  Most readers and implementers won't need to go further.
> 
> I agree with the sentiment — but that’s not what happened with COSE (RFC 8152); IESG is going to insist on either duplicating all the normative content that uses CDDL, in another format (read: plain English (*)), or having a normative reference for CDDL.  I cannot really disagree with that from a formal point of view, so let’s make that happen.
> 
> Grüße, Carsten
> 
> (*) I seriously started writing a CDDL to “plain English” converter, but then the situation defused a bit when the WG almost unanimously decided they wanted to have the CDDL in the main document.
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
> 


From nobody Sun Jul  9 15:55:11 2017
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 CE470120726 for ; Sun,  9 Jul 2017 15:55:08 -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 sUZxDW8466HJ for ; Sun,  9 Jul 2017 15:55:07 -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 9D86012EC11 for ; Sun,  9 Jul 2017 15:55:07 -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 v69Mt3iR002974; Mon, 10 Jul 2017 00:55:03 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x5Nw75QX5z3ZrY; Mon, 10 Jul 2017 00:55:03 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <9eb07cab-7ea4-01eb-2919-1382b8bc72be@gmail.com>
Date: Mon, 10 Jul 2017 00:55:03 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 521333702.985887-dbb429034fb14af54c62e8398eddf425
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <258C92B3-8988-437E-A7D8-65B8B913668C@tzi.org> <9eb07cab-7ea4-01eb-2919-1382b8bc72be@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] CDDL spec should specify how CBOR items match types
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: Sun, 09 Jul 2017 22:55:09 -0000

On Jul 9, 2017, at 22:37, Brian E Carpenter =
 wrote:
>=20
> This argues against inflating CDDL with new features at the moment.
> We can always add features later.

Right, and it is important to have defined extension points for that.

Most of the linear growth of CDDL from -05 to the current -11 happened =
in =E2=80=9Ccontrols=E2=80=9D.  =E2=80=9CControls" used to be called =
=E2=80=9Cannotations=E2=80=9D, because that was the original purpose we =
had in mind, but the construct just turned out to be more useful than =
just that.  The important thing is that new =E2=80=9Ccontrols=E2=80=9D =
can be defined pretty much without disturbing the rest of the language, =
so it would be easy to buffer any new requirements in such add-on specs =
if they fit the construct.

It is much harder to extend a language like CDDL in its foundations.  =
Fortunately, there are some 50 years of theory in computer grammars that =
can help us predict where the path might lead (and which approaches =
might not be so successful).

We don=E2=80=99t have a very good plan for making CDDL useful for =
specific new CBOR tags that are going to be invented (e.g., we don=E2=80=99=
t know the best way an OID tag might be best supported by CDDL).  Much =
can be done with =E2=80=9Ccontrols=E2=80=9D, but there is also literal =
syntax to take care of (maybe that can also be handled with controls, =
just like .bits added something akin to a bit set mechanism to the =
capabilities of CDDL).

After having seen CDDL in use in numerous smaller and not-to-small =
specification projects in more than two years now, I believe -11 is =
pretty much feature complete.  It is likely that one future extension =
will want to enhance the ability of diagnostic tools to provide better =
error messages (again something that probably can be copied from =
existing grammar research; but the work of evaluating what exactly to =
copy hasn=E2=80=99t been done yet and sounds more like a research =
project that might take longer than the WG process).

So I don=E2=80=99t see much danger of CDDL bloating in the WG process =
leading to the first RFC, and I agree it would be good to get agreement =
in the WG about trying to avoid that.

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


From nobody Sun Jul  9 17:22:04 2017
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 E630A131442 for ; Sun,  9 Jul 2017 17:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq26vsKKRvli for ; Sun,  9 Jul 2017 17:21:55 -0700 (PDT)
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 64F4A130141 for ; Sun,  9 Jul 2017 17:21:55 -0700 (PDT)
Received: from sandelman.ca (unknown [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CDC9AE22D; Sun,  9 Jul 2017 20:22:19 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D2DEA84317; Sun,  9 Jul 2017 20:21:29 -0400 (EDT)
From: Michael Richardson 
To: Carsten Bormann 
cc: Brian E Carpenter , cbor@ietf.org
In-Reply-To: 
References:    <258C92B3-8988-437E-A7D8-65B8B913668C@tzi.org> <9eb07cab-7ea4-01eb-2919-1382b8bc72be@gmail.com> 
X-Mailer: MH-E 8.6; nmh 1.6+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: Re: [Cbor] CDDL spec should specify how CBOR items match types
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, 10 Jul 2017 00:22:03 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Carsten Bormann  wrote:
    > Most of the linear growth of CDDL from -05 to the current -11 happened
    > in =E2=80=9Ccontrols=E2=80=9D.  =E2=80=9CControls" used to be called =
=E2=80=9Cannotations=E2=80=9D, because
    > that was the original purpose we had in mind, but the construct just
    > turned out to be more useful than just that.  The important thing is
    > that new =E2=80=9Ccontrols=E2=80=9D can be defined pretty much withou=
t disturbing the
    > rest of the language, so it would be easy to buffer any new
    > requirements in such add-on specs if they fit the construct.

But, since any given draft is going to point at a SPECIFIC version of CDDL,
and we can do forklift upgrades on drafts and RFCs, we don't have to worry
about the same level of "in the field" compatibility.  If we have to,
the CDDL file can start with:

"cddl 2.0"

at the top, and rotate all the operators left if we want.

(I know that you know this...)

    > After having seen CDDL in use in numerous smaller and not-to-small
    > specification projects in more than two years now, I believe -11 is
    > pretty much feature complete.  It is likely that one future extension

Wonderful!

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlliyIkACgkQgItw+93Q
3WUCUgf+O2MjtzE7Ufv7zETgjT0qsmceF5mKCLshoFcqXqJwW41GQPzXuT/bkvt8
otElIogKoOXQz54EMARyvXF+WK4H7XrvTV26tCdO7tRXQH7NZb/FwJXAYKh3TxHx
ndmV+bAsF4dJhSWVvoueQTM1xnSwRwlUGkye5I0aCoZPcAWgBbjXypNnbmXmMhEm
/0YgAdN3JVbotFyRvT4DrVbrZYlpTO/TYgUXo4x52clOxVWEGpnJKmr4WxK5jhTO
F3cXQuU+ygvvpAakud8kG6i1mZ18FBx4yqjCHoL97n1bL4zRNWfX6nBNk+vs7Gi0
P46ExhPnQMdUP3Ql3fqg1I6o3zYoHg==
=SXzn
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Jul 10 13:32:01 2017
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 7544313184D for ; Mon, 10 Jul 2017 13:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W5ieU6bZMdd for ; Mon, 10 Jul 2017 13:31:59 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5545C1318A9 for ; Mon, 10 Jul 2017 13:31:59 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 10 Jul 2017 13:31:56 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 10 Jul 2017 13:31:56 -0700
From: Paul Hoffman 
To: "cbor@ietf.org" 
Thread-Topic: IANA considerations for draft-ietf-cbor-7049bis
Thread-Index: AQHS+buS56mWfI/rT0ym+xZZTpyEMA==
Date: Mon, 10 Jul 2017 20:31:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Cbor] IANA considerations for 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: Mon, 10 Jul 2017 20:32:00 -0000

Greetings again. It seems like draft-ietf-cbor-7049bis is not needing much =
update (or people are being too politely silent...). However, we know that =
we need to do some work on the IANA considerations, Section 7.

Please review the entire section, looking for even small things that we mig=
ht want to fix.

One bigger question I have is whether Table 3 should include all entries in=
 the CBOR Tags registry, or only the ones that were registered with RFC 704=
9. I tend to think the latter is better as long as we make a note that we k=
now that the registry has already been updated multiple times, but would li=
ke to hear other thoughts.

Having some discussion of this on the list before the meeting next week wil=
l make the meeting more valuable.

--Paul Hoffman=


From nobody Tue Jul 11 10:26:09 2017
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 AC93B1316E1; Tue, 11 Jul 2017 10:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level: 
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 De7Vl98DmB6u; Tue, 11 Jul 2017 10:26:05 -0700 (PDT)
Received: from mail4.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 8FBA112EAB0; Tue, 11 Jul 2017 10:26:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499793946; h=from:subject:to:date:message-id; bh=Gi+M1LkKYHDeeilwivsOj5juBRbCzdNRIncOz0YVL6g=; b=iym+4wOg+WfEsKLA0LY10gLDu9Kol+0OQ8k0vWaaeGmKPqYtrfCZaDO5SNEMh+LgaSe+pBZUpZA FVWmFBS2/fvKp8inp+Vb+vdp0+UUbq+Bygx9H9XtkFPq04qCuvRvjGUTHgFhJ0FnquCVSuTsfXd3U Hl9BE9OrMx9M0fMEptYBmpVmuXpjbFQPU70JzTyHQAB+0w6OnIqnh13Jf8igfLiTi0ixKjMFhLpto 0kjTB3TXcZcWYPCFZpdGeKgvQZO7gyPQsAEwSanXJPelmD4ecHsY40GPQXUHe9Db3+SLy2IUgM7Bu wrzrKobDpt54vN9WzG67imK7Ck1uqvWCCeBw==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 10:25:45 -0700
Received: from Hebrews (104.129.192.109) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 10:25:43 -0700
From: Jim Schaad 
To: 
CC: 
Date: Tue, 11 Jul 2017 10:25:50 -0700
Message-ID: <043b01d2fa6a$c05ec780$411c5680$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdL6KixsNg/az58LQGmNrzMX4A17pw==
X-Originating-IP: [104.129.192.109]
Archived-At: 
Subject: [Cbor] 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: Tue, 11 Jul 2017 17:26:07 -0000

Paul,

Here are a few comments for you to mull over.

Section 2.1 - Major type 2 -  After the long discussion in the JSON working
group about bad Unicode code points, it would probably be a good idea to
have a statement here (which I do notice is echoed in other places) about
the fact that the Unicode string must be valid according to some measure of
valid.

Section 2.4.1 - Does it make any sense to put in a comment that the POSIX
time ignores leap seconds

Section 3.3.1 - I do not understand the second bullet item. Either it does
not seem to be an error - or it is the same as the previous item.  Did you
mean to say that the key is processed but the end of the data comes before
the value is processed?

Section 3.3.2 - formatting - why is the last paragraph not a bullet point?

Section 3.7 needs a re-write esp. given that many of the specs are
"violating" the guidance in this section.  Also the use of both signed and
unsigned ints seems to be totally reasonable but also violates the guidance.

Section 3.9 - I will again express unhappiness with the language on sorting
keys.  It would be good to re-write this so that it is clear what is being
done and why.  Having to encode in order to sort is both good and bad.

Section 3.10 - 3 to last paragraph - should 'update the encoder at the same'
be decoder not encoder?

Jim




From nobody Tue Jul 11 11:26:50 2017
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 0203F12EB4E; Tue, 11 Jul 2017 11:26:48 -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 KhjFPLmn2xAA; Tue, 11 Jul 2017 11:26:46 -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 D9A4112EA74; Tue, 11 Jul 2017 11:26:45 -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 v6BIQUX0000167; Tue, 11 Jul 2017 20:26:30 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x6VsL3GBZzDJpg; Tue, 11 Jul 2017 20:26:30 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <043b01d2fa6a$c05ec780$411c5680$@augustcellars.com>
Date: Tue, 11 Jul 2017 20:26:29 +0200
Cc: draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 521490389.128129-4ccd2a8eea3863c9df866d6ae98836b8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <043b01d2fa6a$c05ec780$411c5680$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] 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: Tue, 11 Jul 2017 18:26:48 -0000

Hi Jim,

thank you for the input.

> Section 2.1 - Major type 2 -  After the long discussion in the JSON =
working
> group about bad Unicode code points, it would probably be a good idea =
to
> have a statement here (which I do notice is echoed in other places) =
about
> the fact that the Unicode string must be valid according to some =
measure of
> valid.

(I think this is about major type 3, text strings.  Major type 2 is byte =
strings.)

One way to handle this here might be adding a reference to a =
specification that defines what Unicode is.  Note that CBOR does not =
take a position on many of the minor quibbles in the Unicode world, or =
specify a specific Unicode version =E2=80=94 the intention is that the =
spec grows with the common usage of Unicode.  The only reference that is =
there already is that of UTF-8, and CBOR is intended to be strict about =
that specification.  But I don=E2=80=99t think that, say, CBOR with a =
Unicode non-character, needs to be considered invalid CBOR.

> Section 2.4.1 - Does it make any sense to put in a comment that the =
POSIX
> time ignores leap seconds

It doesn=E2=80=99t ignore those (to the contrary, it creates hard to =
handle non-linearities at exactly those points), it handles them by =
glossing over them in a specific (and not necessarily intuitive) way.
Trying to reproduce the POSIX specification here is likely to create =
more confusion than solve any.
I=E2=80=99m not sure draft-touch-time will be ready in time for this =
document, but it would make a nice informative reference once it is =
done.

> Section 3.3.1 - I do not understand the second bullet item. Either it =
does
> not seem to be an error - or it is the same as the previous item.  Did =
you
> mean to say that the key is processed but the end of the data comes =
before
> the value is processed?

Maybe; maybe that example (the whole list is about examples) is not as =
useful as we thought.

> Section 3.3.2 - formatting - why is the last paragraph not a bullet =
point?

Because it is not about "malformed indefinite-length data items=E2=80=9D =
=E2=80=94 the point in that paragraph is that we don=E2=80=99t have an =
active indefinite-length data item and see a =E2=80=9Cbreak=E2=80=9D =
stop code.

> Section 3.7 needs a re-write esp. given that many of the specs are
> "violating" the guidance in this section.

It sure makes sense to align that guidance with the best practice that =
has evolved since it was written.
What specific parts would you want to change?
(Note that much of the section is about JSON interoperability, which =
maybe should be more clearly separated from more general =
considerations.)

> Also the use of both signed and
> unsigned ints seems to be totally reasonable but also violates the =
guidance.

The last paragraph actually recommends that =E2=80=94 what other parts =
of the guidance are being violated?

> Section 3.9 - I will again express unhappiness with the language on =
sorting
> keys.  It would be good to re-write this so that it is clear what is =
being
> done and why.  Having to encode in order to sort is both good and bad.

Yes, when I wrote the cbor-canonical addition to the cbor-ruby gem, I =
decided to simply encode everything in a map key twice=E2=80=A6

One problem is that the map key ordering spec violates the POLS =
(principle of least surprise): Most people would expect lexicographical =
order (in the computer science sense of that word) here.  That order =
also has certain performance advantages (it may be possible to decide on =
the order between two items before looking at the entire items).  But =
that is not what the spec currently says, and so far we haven=E2=80=99t =
heard that this guidance really needs to change.

The parenthetical recommendation against mixing types of keys probably =
should go; implementations have generally managed to avoid the pitfalls =
here.

> Section 3.10 - 3 to last paragraph - should 'update the encoder at the =
same'
> be decoder not encoder?

Well, maybe encoding/decoding layer=E2=80=A6. But yes, the specific =
sentence is about the decoder.

Thanks again; more input on potential editorial improvements is very =
welcome.

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


From nobody Tue Jul 11 12:04:58 2017
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 6C7C61317AD for ; Tue, 11 Jul 2017 12:04:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 vZ3Ib3wLpGto for ; Tue, 11 Jul 2017 12:04:56 -0700 (PDT)
Received: from mail4.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 3479E129B34 for ; Tue, 11 Jul 2017 12:04:56 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499799879; h=from:subject:to:date:message-id; bh=qPJedmJOjhWWNJ1O/1rmnBtwCAA9g8m0hIw+ktn3O34=; b=KKSaCjbBo9mNDieAjUssaDZRduHMRxFvimlokH7H/THDxTY4mB/dVnENAhjvFwqmoo2g8tnK+wi 0jlkxpEX4TBhToKYGO8W0nZ7zguydlOmEGMFEKd16zM4pbEr5VZUtDUmjxD+CoycOFYpy1OV19xJ6 clKs6qv6jKlqyXopDG1eG6w+ced2Q3oVeaVtgaIeC//3zGHa3ogi2T5Ii+0mmGZu7M1/f8chZ1HJF oxpLnkk+6NDQgeeFnZnNhvRNixU/tAfH7e+gOm51hJa03Sbwx70KRV57J+0wAk6fkrpywzGZOKaCA 4pysEYurVD2R1cfXkLXirNMLjNlmDTHnZ+Lg==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 12:04:37 -0700
Received: from Hebrews (104.129.192.109) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 12:04:36 -0700
From: Jim Schaad 
To: 
Date: Tue, 11 Jul 2017 12:04:45 -0700
Message-ID: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdL6caAX+6csORz9R8mq25LivXKLyQ==
X-Originating-IP: [104.129.192.109]
Archived-At: 
Subject: [Cbor] Application specific tagging
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: Tue, 11 Jul 2017 19:04:57 -0000

I have not really thought this through, and I don't know that it can easily
be implemented in such a way as to make it small.  

It might be nice to define the ability for an application specific tagging
mechanism to be defined.  While this to some extent can be thought of as
duplicating the functionality of maps, when one wants to do a more canonical
encoding it will produce smaller data than having a key for every field.

Consider the following

Array_item = [
   version: int,
   field1 : int,
   ? field2 : int,
   field 3 : int,
   ? field4 : int
]

As written, while the syntax is valid one cannot decide for [ 9, 10, 11, 12]
which of the fields are present and which are absent.  ASN.1 solves this
problem by the ability to do tagging so that one can write

Array_item = [
   version: int,
   field1 : int,
   ? [1] field2 : int,
   field 3 : int,
   ? [2] field4 : int
]

And now it is easy to identify which field is present.   

However this leads to problems in trying to determine how to actually encode
in CBOR.  While the nice thing would be to do something like  [9, 10, 11,
2(12)] so that you have a a tag which  has arbitrary cbor as a child.  This
is not currently something that can be written.  The best I can come up with
at the moment would be [9, 10, 11, X([2, 12])] but I would like to not have
the array.

Note that this might be helpful for the SEML people as I seem to remember an
argument where application tagging was needed.

Jim



From nobody Tue Jul 11 12:17:13 2017
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 A8FF9131774 for ; Tue, 11 Jul 2017 12:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level: 
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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=qti.qualcomm.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 1v8n1oYaVFsg for ; Tue, 11 Jul 2017 12:17:11 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBE3129B66 for ; Tue, 11 Jul 2017 12:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499800631; x=1531336631; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wVhEEIpytrlZMsczVUTPyh4mD4yMghjpLa+S4pbD7UA=; b=uAytyyb7Iw9CAOwBR18RiboC1CPG9bwxtQuByDGVfWA9VDj+puOmwUwv qh5rk3B9rZtm8NEwKCk0qETO8BShFQSL+/SBn/TBxy11B+WX6r8Xyo2Zt jL/38Q4TXrxHpup6+/ikcdLkfLdtvYr+tkc0Q7rMs/rMFXwYaeQrNBrVH A=;
X-IronPort-AV: E=Sophos;i="5.40,347,1496127600"; d="scan'208";a="110186943"
Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by sabertooth01.qualcomm.com with ESMTP; 11 Jul 2017 12:17:10 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8588"; a="962894841"
X-MGA-submission: =?us-ascii?q?MDHzaexwrLnXxIbxhHyNc3NXirkh54sjMM0o/e?= =?us-ascii?q?coHA/zSEoWFNipxbaeVLpFVyvc6Qu54VxuQIQAqSRrqnktGjSmp7hA2O?= =?us-ascii?q?W6bDdmuP4aDaBTBg+4Mpt1X4XX3Tm/ubjASMccuxB5Vxb2MN1SW02l5z?= =?us-ascii?q?i+?=
Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Jul 2017 12:17:10 -0700
Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 11 Jul 2017 12:17:09 -0700
Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Tue, 11 Jul 2017 12:17:09 -0700
From: Laurence Lundblade 
To: Jim Schaad 
CC: "cbor@ietf.org" 
Thread-Topic: [Cbor] Application specific tagging
Thread-Index: AdL6caAX+6csORz9R8mq25LivXKLyQAQ1YsA
Date: Tue, 11 Jul 2017 19:17:08 +0000
Message-ID: 
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>
In-Reply-To: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6206472539770149827441ECA58DCA08@qualcomm.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Tue, 11 Jul 2017 19:17:12 -0000

TWFwcyB3aXRoIHNtYWxsIGludGVnZXIga2V5cyBhcmUgdmVyeSBjaGVhcCBpbiBDQk9SLiBZb3Ug
Y2Fu4oCZdCBleHByZXNzIHRoaXMgaW4gSlNPTiBlYXNpbHkuIFdvdWxkIGJlIGhlc2l0YW50IHRv
IGFkZCB0aGUgY29tcGxleGl0eSB3aXRob3V0IGEgY29tcGVsbGluZyBleGFtcGxlLg0KDQpMTA0K
DQo+IE9uIEp1bCAxMSwgMjAxNywgYXQgMTI6MDQgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0
Y2VsbGFycy5jb20+IHdyb3RlOg0KPiANCj4gSSBoYXZlIG5vdCByZWFsbHkgdGhvdWdodCB0aGlz
IHRocm91Z2gsIGFuZCBJIGRvbid0IGtub3cgdGhhdCBpdCBjYW4gZWFzaWx5DQo+IGJlIGltcGxl
bWVudGVkIGluIHN1Y2ggYSB3YXkgYXMgdG8gbWFrZSBpdCBzbWFsbC4gIA0KPiANCj4gSXQgbWln
aHQgYmUgbmljZSB0byBkZWZpbmUgdGhlIGFiaWxpdHkgZm9yIGFuIGFwcGxpY2F0aW9uIHNwZWNp
ZmljIHRhZ2dpbmcNCj4gbWVjaGFuaXNtIHRvIGJlIGRlZmluZWQuICBXaGlsZSB0aGlzIHRvIHNv
bWUgZXh0ZW50IGNhbiBiZSB0aG91Z2h0IG9mIGFzDQo+IGR1cGxpY2F0aW5nIHRoZSBmdW5jdGlv
bmFsaXR5IG9mIG1hcHMsIHdoZW4gb25lIHdhbnRzIHRvIGRvIGEgbW9yZSBjYW5vbmljYWwNCj4g
ZW5jb2RpbmcgaXQgd2lsbCBwcm9kdWNlIHNtYWxsZXIgZGF0YSB0aGFuIGhhdmluZyBhIGtleSBm
b3IgZXZlcnkgZmllbGQuDQo+IA0KPiBDb25zaWRlciB0aGUgZm9sbG93aW5nDQo+IA0KPiBBcnJh
eV9pdGVtID0gWw0KPiAgIHZlcnNpb246IGludCwNCj4gICBmaWVsZDEgOiBpbnQsDQo+ICAgPyBm
aWVsZDIgOiBpbnQsDQo+ICAgZmllbGQgMyA6IGludCwNCj4gICA/IGZpZWxkNCA6IGludA0KPiBd
DQo+IA0KPiBBcyB3cml0dGVuLCB3aGlsZSB0aGUgc3ludGF4IGlzIHZhbGlkIG9uZSBjYW5ub3Qg
ZGVjaWRlIGZvciBbIDksIDEwLCAxMSwgMTJdDQo+IHdoaWNoIG9mIHRoZSBmaWVsZHMgYXJlIHBy
ZXNlbnQgYW5kIHdoaWNoIGFyZSBhYnNlbnQuICBBU04uMSBzb2x2ZXMgdGhpcw0KPiBwcm9ibGVt
IGJ5IHRoZSBhYmlsaXR5IHRvIGRvIHRhZ2dpbmcgc28gdGhhdCBvbmUgY2FuIHdyaXRlDQo+IA0K
PiBBcnJheV9pdGVtID0gWw0KPiAgIHZlcnNpb246IGludCwNCj4gICBmaWVsZDEgOiBpbnQsDQo+
ICAgPyBbMV0gZmllbGQyIDogaW50LA0KPiAgIGZpZWxkIDMgOiBpbnQsDQo+ICAgPyBbMl0gZmll
bGQ0IDogaW50DQo+IF0NCj4gDQo+IEFuZCBub3cgaXQgaXMgZWFzeSB0byBpZGVudGlmeSB3aGlj
aCBmaWVsZCBpcyBwcmVzZW50LiAgIA0KPiANCj4gSG93ZXZlciB0aGlzIGxlYWRzIHRvIHByb2Js
ZW1zIGluIHRyeWluZyB0byBkZXRlcm1pbmUgaG93IHRvIGFjdHVhbGx5IGVuY29kZQ0KPiBpbiBD
Qk9SLiAgV2hpbGUgdGhlIG5pY2UgdGhpbmcgd291bGQgYmUgdG8gZG8gc29tZXRoaW5nIGxpa2Ug
IFs5LCAxMCwgMTEsDQo+IDIoMTIpXSBzbyB0aGF0IHlvdSBoYXZlIGEgYSB0YWcgd2hpY2ggIGhh
cyBhcmJpdHJhcnkgY2JvciBhcyBhIGNoaWxkLiAgVGhpcw0KPiBpcyBub3QgY3VycmVudGx5IHNv
bWV0aGluZyB0aGF0IGNhbiBiZSB3cml0dGVuLiAgVGhlIGJlc3QgSSBjYW4gY29tZSB1cCB3aXRo
DQo+IGF0IHRoZSBtb21lbnQgd291bGQgYmUgWzksIDEwLCAxMSwgWChbMiwgMTJdKV0gYnV0IEkg
d291bGQgbGlrZSB0byBub3QgaGF2ZQ0KPiB0aGUgYXJyYXkuDQo+IA0KPiBOb3RlIHRoYXQgdGhp
cyBtaWdodCBiZSBoZWxwZnVsIGZvciB0aGUgU0VNTCBwZW9wbGUgYXMgSSBzZWVtIHRvIHJlbWVt
YmVyIGFuDQo+IGFyZ3VtZW50IHdoZXJlIGFwcGxpY2F0aW9uIHRhZ2dpbmcgd2FzIG5lZWRlZC4N
Cj4gDQo+IEppbQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IENCT1IgbWFpbGluZyBsaXN0DQo+IENCT1JAaWV0Zi5vcmcNCj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQoNCg==


From nobody Tue Jul 11 12:17:29 2017
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 5D52512009C; Tue, 11 Jul 2017 12:17:27 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Joac5TcAOjJN; Tue, 11 Jul 2017 12:17:25 -0700 (PDT)
Received: from mail4.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 8BCEB129B66; Tue, 11 Jul 2017 12:17:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499800624; h=from:subject:to:date:message-id; bh=1APghR3P4yIIH94kdeT14AiXUKjiljxO81nzbAV3v7k=; b=JRWXHyMyPyn+rKnKrMAPzJ+x90C8ffxy36WZIHx4V0iaBXqCRSmTnT4B7cVVLQK6RiXkys5KaDO 6Z/9+rB6QMyCpYK4jZP4nBPQ8dx0SLXbXLRbnjGXpqvacgOHHHgBBAKbRQ3Ef3RDFxO3J7p8YooU1 yNq7n3BEKgeaDwCRBZ7bER7fre/CaZYQA5b/55NShpJgEnHqh+7P+tsWUOwpZTC6hcOSm//JvVvVf Gy2YF4lhImODY0JRd1rnWKDGRJL7eGbl4YKniMKQHoKLvCUOikp39zBL5ic3R+yroJhmUhYRAap1A 3YocBXyW3Q/Tn+94boUsx+sv2eJP/Fa96Ang==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 12:17:03 -0700
Received: from Hebrews (104.129.192.109) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Jul 2017 12:17:02 -0700
From: Jim Schaad 
To: 'Carsten Bormann' 
CC: , 
References: <043b01d2fa6a$c05ec780$411c5680$@augustcellars.com> 
In-Reply-To: 
Date: Tue, 11 Jul 2017 12:17:10 -0700
Message-ID: <044b01d2fa7a$4da21e30$e8e65a90$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGBZv7+sRdyd/cqqfJTztwXCsd/DgIc3dxoouE83iA=
X-Originating-IP: [104.129.192.109]
Archived-At: 
Subject: Re: [Cbor] 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: Tue, 11 Jul 2017 19:17:27 -0000

Some responses inline.

Jim


-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]=20
Sent: Tuesday, July 11, 2017 11:26 AM
To: Jim Schaad 
Cc: draft-ietf-cbor-7049bis@ietf.org; cbor@ietf.org
Subject: Re: draft-ietf-cbor-7049bis=20

Hi Jim,

thank you for the input.

> Section 2.1 - Major type 2 -  After the long discussion in the JSON=20
> working group about bad Unicode code points, it would probably be a=20
> good idea to have a statement here (which I do notice is echoed in=20
> other places) about the fact that the Unicode string must be valid=20
> according to some measure of valid.

(I think this is about major type 3, text strings.  Major type 2 is byte =
strings.)

[JLS] That is what I get for making notes and then trying to flesh them =
out rather than writing the full comment at the time.

One way to handle this here might be adding a reference to a =
specification that defines what Unicode is.  Note that CBOR does not =
take a position on many of the minor quibbles in the Unicode world, or =
specify a specific Unicode version =E2=80=94 the intention is that the =
spec grows with the common usage of Unicode.  The only reference that is =
there already is that of UTF-8, and CBOR is intended to be strict about =
that specification.  But I don=E2=80=99t think that, say, CBOR with a =
Unicode non-character, needs to be considered invalid CBOR.

[JLS] I cannot remember what the decision that JSON made about this.  I =
would say that we should be making the same answer here.

> Section 2.4.1 - Does it make any sense to put in a comment that the=20
> POSIX time ignores leap seconds

It doesn=E2=80=99t ignore those (to the contrary, it creates hard to =
handle non-linearities at exactly those points), it handles them by =
glossing over them in a specific (and not necessarily intuitive) way.
Trying to reproduce the POSIX specification here is likely to create =
more confusion than solve any.
I=E2=80=99m not sure draft-touch-time will be ready in time for this =
document, but it would make a nice informative reference once it is =
done.

[JLS] I think we are saying the same thing.  The time computation =
pretends that leap seconds never existed. However, I don't need to have =
that mentioned which is why I was asking if it made sense.

> Section 3.3.1 - I do not understand the second bullet item. Either it=20
> does not seem to be an error - or it is the same as the previous item. =
=20
> Did you mean to say that the key is processed but the end of the data=20
> comes before the value is processed?

Maybe; maybe that example (the whole list is about examples) is not as =
useful as we thought.

> Section 3.3.2 - formatting - why is the last paragraph not a bullet =
point?

Because it is not about "malformed indefinite-length data items=E2=80=9D =
=E2=80=94 the point in that paragraph is that we don=E2=80=99t have an =
active indefinite-length data item and see a =E2=80=9Cbreak=E2=80=9D =
stop code.

[JLS] I would have called it a malformed indefinite length encoding - so =
it makes more sense to me as a bullet point.  I can deal with this as =
is, I just think it reads better the other way.

> Section 3.7 needs a re-write esp. given that many of the specs are=20
> "violating" the guidance in this section.

It sure makes sense to align that guidance with the best practice that =
has evolved since it was written.
What specific parts would you want to change?
(Note that much of the section is about JSON interoperability, which =
maybe should be more clearly separated from more general =
considerations.)

> Also the use of both signed and
> unsigned ints seems to be totally reasonable but also violates the =
guidance.

The last paragraph actually recommends that =E2=80=94 what other parts =
of the guidance are being violated?

[JLS] It depends on if you think that the union of signed and unsigned =
is a single type or if it is two types.  I think of it as two types =
since the major type number is different.

> Section 3.9 - I will again express unhappiness with the language on=20
> sorting keys.  It would be good to re-write this so that it is clear=20
> what is being done and why.  Having to encode in order to sort is both =
good and bad.

Yes, when I wrote the cbor-canonical addition to the cbor-ruby gem, I =
decided to simply encode everything in a map key twice=E2=80=A6

One problem is that the map key ordering spec violates the POLS =
(principle of least surprise): Most people would expect lexicographical =
order (in the computer science sense of that word) here.  That order =
also has certain performance advantages (it may be possible to decide on =
the order between two items before looking at the entire items).  But =
that is not what the spec currently says, and so far we haven=E2=80=99t =
heard that this guidance really needs to change.

[JLS] I would be really happy to stop this violation of POLS.  We have =
some discussions on that during last call on the current RFC.

The parenthetical recommendation against mixing types of keys probably =
should go; implementations have generally managed to avoid the pitfalls =
here.

> Section 3.10 - 3 to last paragraph - should 'update the encoder at the =
same'
> be decoder not encoder?

Well, maybe encoding/decoding layer=E2=80=A6. But yes, the specific =
sentence is about the decoder.

Thanks again; more input on potential editorial improvements is very =
welcome.

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



From nobody Tue Jul 11 12:32:25 2017
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 8DC981316A5 for ; Tue, 11 Jul 2017 12:32:24 -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 bqmBQM0_TJTK for ; Tue, 11 Jul 2017 12:32:20 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8481317B7 for ; Tue, 11 Jul 2017 12:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6BJVXvc023066; Tue, 11 Jul 2017 21:31:33 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x6XJP0yj3zDJq1; Tue, 11 Jul 2017 21:31:33 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>
Date: Tue, 11 Jul 2017 21:31:32 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 521494292.506715-025c944d3464eb47c8804b6726598488
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C9A56D3-7CE9-4FA2-BEEC-A2226EBC053E@tzi.org>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Tue, 11 Jul 2017 19:32:24 -0000

On Jul 11, 2017, at 21:04, Jim Schaad  wrote:
>=20
> Array_item =3D [
>   version: int,
>   field1 : int,
>   ? [1] field2 : int,
>   field 3 : int,
>   ? [2] field4 : int
> ]

I=E2=80=99d solve this as

Array_item =3D [
  version: int,
  field1 : int,
  field2 : int / nil,
  field3 : int,
  ? field4 : int
]

This is more compact than any tagging scheme I can come up with.

(It would not be hard to reserve a number of CBOR tags for =
application-specific tagging.
I=E2=80=99ll actually come up with a rather different application for =
this very soon;
those who were in the W3C WoT meeting today have gotten a glimpse.)

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


From nobody Wed Jul 12 01:32:51 2017
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 70D97128768; Wed, 12 Jul 2017 01:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level: 
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 bKDGbHWZXNF8; Wed, 12 Jul 2017 01:32:48 -0700 (PDT)
Received: from mail4.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 6A24E126E64; Wed, 12 Jul 2017 01:32:45 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499848351; h=from:subject:to:date:message-id; bh=WcCuOuo4donnWBIHUySuJGEA791gAvGR8tcuA87eXvE=; b=ceYBRCYlKurZP0AZxAYgpydt3txOMFwZJ2xqvKp8RJx/quAo/vQh1QM76PSc8j4e+55Xjax5mtd GV1schk9mV9AgoJwiZTYRlmk0SpW5JmJcXPSpXCf7aQRLD/HaN3RmlijNXlII7mjKXLBgYIntFZJi 5ZnwUhZFUq1RUjrlyKj77Kwl/yd6GJuP2UrnxxZW0pXu5gqDKrd2SinKq8w/1PY336fuay3iT6FSM xugIvzFZYZ05qj2EJAcJQFrDi0ExBhvMPhLEzcXqr63GTxTFjy0ows/vS+3TVIhLrpMfA0SkXWemU +FVMpIdVT/iT0XcjxKS6e4CDBjoZl2zNQx+g==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:32:31 -0700
Received: from Hebrews (88.128.81.32) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:32:26 -0700
From: Jim Schaad 
To: 
CC: 
Date: Wed, 12 Jul 2017 01:32:33 -0700
Message-ID: <044c01d2fae9$6b559320$4200b960$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdL60ebGduaFwk0ARbyDuFNzrOO6EA==
X-Originating-IP: [88.128.81.32]
Archived-At: 
Subject: [Cbor] draft-bormann-cbor-time-tag
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: Wed, 12 Jul 2017 08:32:49 -0000

I would expand section 3.2 to include an example.  I did not understand how
this was going to work the first time that I read through it.  I would also
note that this is called a Decimal Fraction in 7049bis.

I think it may be useful to allow for multiple value in section 3.3 to be
present.  In this case only one should be used, the most precise one needed
for the application.

Jim
 


From nobody Wed Jul 12 01:33:13 2017
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 74025128768; Wed, 12 Jul 2017 01:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level: 
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 V0gLW-1zocuJ; Wed, 12 Jul 2017 01:33:10 -0700 (PDT)
Received: from mail4.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 B2267126E64; Wed, 12 Jul 2017 01:33:07 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499848375; h=from:subject:to:date:message-id; bh=IP9KLIW4x/e3tIIYoXiVyO99MW/qumOQJf9u3AfD/DA=; b=GoSLHiAI8PabuW5Uxoy7m3/BTAOF7+K9oiXfhQ0LGZEgKNESiBw5bwktToojfl+/QF0hRmV77C2 GHnS9BrLLm5YPXhA63zLOu2owN6sdGM3jswuLv2/PPpgB4FYybQRMQgMZtJu5Gcu/bMn0ONkTXHZb OPwZdoN2lLytNq9igopSLQP9cysplh2ZEe2OXiT9zgGF32373fFVuGo+ps4fGdrjybI9B35xXEgNX mQ+/GbOxAEthHsbNLHf+5L6x29lz9eYE81Yruwt+f605PbPDL5v9lrXLbhmvuYKYZtqS08l/eypan hKwH8LneyTNqz66CTC5GFMfL+gUyVQVl4rxQ==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:32:55 -0700
Received: from Hebrews (88.128.81.32) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:32:29 -0700
From: Jim Schaad 
To: 
CC: 
Date: Wed, 12 Jul 2017 01:32:33 -0700
Message-ID: <044d01d2fae9$6d69a610$483cf230$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdL60XxF5n3zWm2WTkyehkKhRA5qlg==
X-Originating-IP: [88.128.81.32]
Archived-At: 
Subject: [Cbor] draft-bormann-lpwan-cbor-template
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: Wed, 12 Jul 2017 08:33:11 -0000

There is a security consideration that should probably be mentioned.

If a signed value includes the variables to be substituted, but does not
contain a unique identifier for the template, then the structure resulting
in substituting the variables in the template must not be considered as
having been signed.  Identifying templates by a hash or identifier and
version number is recommended.

Jim



From nobody Wed Jul 12 01:41:22 2017
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 2BF3B12EC3B; Wed, 12 Jul 2017 01:41:21 -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 zP6eW36D9Qis; Wed, 12 Jul 2017 01:41:19 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F224B128768; Wed, 12 Jul 2017 01:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6C8else014170; Wed, 12 Jul 2017 10:40:47 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7E215.dip0.t-ipconnect.de [93.199.226.21]) (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 3x6sq30S4PzDJwX; Wed, 12 Jul 2017 10:40:47 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <044d01d2fae9$6d69a610$483cf230$@augustcellars.com>
Date: Wed, 12 Jul 2017 10:40:45 +0200
Cc: draft-bormann-lpwan-cbor-template@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 521541645.179256-24aa4a339d8f323b48ea513d1778dc1d
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B877075-AAE0-4852-BC1A-AF80A25684B3@tzi.org>
References: <044d01d2fae9$6d69a610$483cf230$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] draft-bormann-lpwan-cbor-template
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: Wed, 12 Jul 2017 08:41:21 -0000

Hi Jim,

thank you!

I put that in (slightly changing the text about version numbers).

Will submit when the I-D directory opens again.

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

> On Jul 12, 2017, at 10:32, Jim Schaad  wrote:
>=20
> If a signed value includes the variables to be substituted, but does =
not
> contain a unique identifier for the template, then the structure =
resulting
> in substituting the variables in the template must not be considered =
as
> having been signed.  Identifying templates by a hash or identifier and
> version number is recommended.


From nobody Wed Jul 12 01:52:22 2017
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 9656E12EC3B for ; Wed, 12 Jul 2017 01:52:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 L6m1UNkOtKYc for ; Wed, 12 Jul 2017 01:52:19 -0700 (PDT)
Received: from mail4.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 2FCBF12708C for ; Wed, 12 Jul 2017 01:52:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499849527; h=from:subject:to:date:message-id; bh=4IfTibMQ6s9q6dsbwRSVko2LyETVwuuctr+tAEcvohg=; b=djzGhmb0exDPTdXFhulX7jrkqKJAaD18ucrQ1meb79PIW5+kZTdcp9fkfeGO9PV3xewQ1rqn0FH Ysfpbc49d3mWm8c9A/aFVfaI8ZH5jSjPbXHOiK9vzlTeWww4kkqqka2ihSC/ceJWZVxVfqkeX/ojy 028+pd3EV+PWrG3xznMYPMZu0rprmt+xXx1NCd07w01cUyf1JUp5XTbfmXVi9ML9wtUFKKx980hzK w01X1m+549abx3+jjDcwbYbtpheU3A9/L04HyLQ/k/WxFN+QxSxdUvweXH9gpqXWVO9r/AFLwNf9u +FuKfBVMb5XzyhKEHHxzFyDpVxnhtdZ5/CmQ==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:52:06 -0700
Received: from Hebrews (88.128.81.32) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:52:02 -0700
From: Jim Schaad 
To: 'Laurence Lundblade' 
CC: 
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com> 
In-Reply-To: 
Date: Wed, 12 Jul 2017 10:52:09 +0200
Message-ID: <04b201d2faec$28738190$795a84b0$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQILLSdxBIs55cZzTK7N0qbZTFRM4AItMfttoc4UMsA=
X-Originating-IP: [88.128.81.32]
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 08:52:21 -0000

That is true for relatively small maps.  If you get a large enough map =
then things start going down hill.

Also, part of my worry was the question of getting a canonicalization.  =
I find this to be difficult with maps but not with arrays.

Jim

-----Original Message-----
From: Laurence Lundblade [mailto:llundbla@qti.qualcomm.com]=20
Sent: Tuesday, July 11, 2017 9:17 PM
To: Jim Schaad 
Cc: cbor@ietf.org
Subject: Re: [Cbor] Application specific tagging

Maps with small integer keys are very cheap in CBOR. You can=E2=80=99t =
express this in JSON easily. Would be hesitant to add the complexity =
without a compelling example.

LL

> On Jul 11, 2017, at 12:04 PM, Jim Schaad  =
wrote:
>=20
> I have not really thought this through, and I don't know that it can=20
> easily be implemented in such a way as to make it small.
>=20
> It might be nice to define the ability for an application specific=20
> tagging mechanism to be defined.  While this to some extent can be=20
> thought of as duplicating the functionality of maps, when one wants to =

> do a more canonical encoding it will produce smaller data than having =
a key for every field.
>=20
> Consider the following
>=20
> Array_item =3D [
>   version: int,
>   field1 : int,
>   ? field2 : int,
>   field 3 : int,
>   ? field4 : int
> ]
>=20
> As written, while the syntax is valid one cannot decide for [ 9, 10,=20
> 11, 12] which of the fields are present and which are absent.  ASN.1=20
> solves this problem by the ability to do tagging so that one can write
>=20
> Array_item =3D [
>   version: int,
>   field1 : int,
>   ? [1] field2 : int,
>   field 3 : int,
>   ? [2] field4 : int
> ]
>=20
> And now it is easy to identify which field is present.  =20
>=20
> However this leads to problems in trying to determine how to actually=20
> encode in CBOR.  While the nice thing would be to do something like =20
> [9, 10, 11, 2(12)] so that you have a a tag which  has arbitrary cbor=20
> as a child.  This is not currently something that can be written.  The =

> best I can come up with at the moment would be [9, 10, 11, X([2, 12])] =

> but I would like to not have the array.
>=20
> Note that this might be helpful for the SEML people as I seem to=20
> remember an argument where application tagging was needed.
>=20
> Jim
>=20
>=20
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor



From nobody Wed Jul 12 01:52:59 2017
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 CAE3012EC3B for ; Wed, 12 Jul 2017 01:52:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 GmzPaWULfymt for ; Wed, 12 Jul 2017 01:52:56 -0700 (PDT)
Received: from mail4.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 923F712708C for ; Wed, 12 Jul 2017 01:52:56 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499849564; h=from:subject:to:date:message-id; bh=P8v7S1tWpz4vBFPHfcvg+thZ3SmNb7dKYfBj6yRy+nk=; b=ZivQiRwcVHQapWjO3KIiyqpeCLd4ocSvj1x41rhB9/kAaQWaRL/s7EnN9iKLWOIzw42S2mMME8l 2RPSsjarxqGkeA/pbu5PhQYLOmxIOlpSOTwT/nE4ZRgPtflEFiUfhWlQwl1Hzgv+ffkmYiHitpOfD RYuGZJxPnUt/uh0uNRjtEXdpAbGWGs6t8tkICl8S9Vl9RYOZqeXSVz5Ypm+ZU5h7eAJg+mCDP9P33 yECgy7eLvvvaOWnZconM4u8QjapeQ9WnNVqJMeCXCyF4pLyJaZLgJvcCJQ81kFWgvj6TxP1rze5uV KiLXY/JB3S8opynelmyxVWlObSROIYu0yzNA==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:52:44 -0700
Received: from Hebrews (88.128.81.32) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Jul 2017 01:52:39 -0700
From: Jim Schaad 
To: 'Carsten Bormann' 
CC: 
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com> <4C9A56D3-7CE9-4FA2-BEEC-A2226EBC053E@tzi.org>
In-Reply-To: <4C9A56D3-7CE9-4FA2-BEEC-A2226EBC053E@tzi.org>
Date: Wed, 12 Jul 2017 10:52:47 +0200
Message-ID: <04b301d2faec$3e6d44e0$bb47cea0$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQILLSdxBIs55cZzTK7N0qbZTFRM4AKNWfHjocsTNOA=
X-Originating-IP: [88.128.81.32]
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 08:52:58 -0000

Yes, that is how I have done it today in the COSE spec.  However, I =
think it might be a useful feature to kick around and see if it can be =
done.

Jim


-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]=20
Sent: Tuesday, July 11, 2017 9:32 PM
To: Jim Schaad 
Cc: cbor@ietf.org
Subject: Re: [Cbor] Application specific tagging

On Jul 11, 2017, at 21:04, Jim Schaad  wrote:
>=20
> Array_item =3D [
>   version: int,
>   field1 : int,
>   ? [1] field2 : int,
>   field 3 : int,
>   ? [2] field4 : int
> ]

I=E2=80=99d solve this as

Array_item =3D [
  version: int,
  field1 : int,
  field2 : int / nil,
  field3 : int,
  ? field4 : int
]

This is more compact than any tagging scheme I can come up with.

(It would not be hard to reserve a number of CBOR tags for =
application-specific tagging.
I=E2=80=99ll actually come up with a rather different application for =
this very soon; those who were in the W3C WoT meeting today have gotten =
a glimpse.)

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


From nobody Wed Jul 12 07:43:46 2017
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 9D8A012EC39 for ; Wed, 12 Jul 2017 07:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_hMl48vNT-9 for ; Wed, 12 Jul 2017 07:43:43 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8326D129ADA for ; Wed, 12 Jul 2017 07:43:43 -0700 (PDT)
Received: from [169.254.159.195] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v6CEgUO2009948 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Jul 2017 07:42:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.159.195]
From: "Paul Hoffman" 
To: "Jim Schaad" 
Cc: cbor@ietf.org
Date: Wed, 12 Jul 2017 07:43:25 -0700
Message-ID: 
In-Reply-To: <04b301d2faec$3e6d44e0$bb47cea0$@augustcellars.com>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com> <4C9A56D3-7CE9-4FA2-BEEC-A2226EBC053E@tzi.org> <04b301d2faec$3e6d44e0$bb47cea0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 14:43:45 -0000

On 12 Jul 2017, at 1:52, Jim Schaad wrote:

> Yes, that is how I have done it today in the COSE spec.  However, I 
> think it might be a useful feature to kick around and see if it can be 
> done.

I respectfully disagree. Its use in ASN.1 has always been problematic 
for data designers, and I think we had some problems with some proposed 
CMS specs that only got caught late in the process.

A better design rule is "if you have optional fields, it's an object".

--Paul Hoffman


From nobody Wed Jul 12 10:24:51 2017
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 98057129B10 for ; Wed, 12 Jul 2017 10:24:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 vpZbwhacZRTg for ; Wed, 12 Jul 2017 10:24:46 -0700 (PDT)
Received: from alexa-out-lv-02.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC3E1316EE for ; Wed, 12 Jul 2017 10:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499880279; x=1531416279; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8bdiFbQLIx3q0VaMPzoBIWg5z9ZooL3obxpM9D/mjMk=; b=HXOUmuNFAEXc3poc/WabPBwPhGNNciMWYVQP3jYT/iFFgsXDo1anV0Mi 92E3cCeo44xx2lWTYxjKdjeMA2iXAoaTSLAHJtDTKGWj0+CC6xjfOosAh Xsq6FxAMSjrqS9wIsidbZYM6mvnT8a2SOyxMIWZkHdLr2rFR3uMRwiiIt Y=;
X-IronPort-AV: E=Sophos;i="5.40,350,1496127600";  d="scan'208";a="826501"
Received: from ironmsg04-l-new.qualcomm.com (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by alexa-out-lv-02.qualcomm.com with ESMTP; 12 Jul 2017 10:24:38 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8589"; a="1385906467"
X-MGA-submission: =?us-ascii?q?MDGbkbwLQcey+z6ElgVJAU6Tz2R5NaRRS06JbC?= =?us-ascii?q?vi3SaB7ReAbu6jsd1isvPu6NtpGF8kINE2mdJstEod3x5Gi+4jFtrgxW?= =?us-ascii?q?XcvR8gFCzqU4cJHuNWyNQJO9JEJKdQNrV2YWKHG5hh0iWB/msKWqcbG5?= =?us-ascii?q?fD?=
Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Jul 2017 10:24:38 -0700
Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 12 Jul 2017 10:24:37 -0700
Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Wed, 12 Jul 2017 10:24:37 -0700
From: Laurence Lundblade 
To: Jim Schaad 
CC: "cbor@ietf.org" 
Thread-Topic: [Cbor] Application specific tagging
Thread-Index: AdL6caAX+6csORz9R8mq25LivXKLyQAQ1YsAABx20YAAEeX2AA==
Date: Wed, 12 Jul 2017 17:24:37 +0000
Message-ID: <15725A02-2F36-4CC3-98B7-4BD49F6B68BE@qti.qualcomm.com>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>  <04b201d2faec$28738190$795a84b0$@augustcellars.com>
In-Reply-To: <04b201d2faec$28738190$795a84b0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <48BEA586D80CB749BE8F8C301507B270@qualcomm.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 17:24:49 -0000

V2hhdCBpcyB0aGUgaXNzdWUgd2l0aCBjYW5vbmljYWxpemF0aW9uIG9mIG1hcHM/ICBJIGNhbuKA
mXQgdGhpbmsgb2Ygd2hhdCBpdCBpcywgYnV0IGhvcGVmdWxseSBpdCBpcyBqdXN0IG1pbGRseSBp
bmNvbnZlbmllbnQsIG5vdCBhY3R1YWxseSBkaWZmaWN1bHQuDQoNCkxMDQoNCg0KPiBPbiBKdWwg
MTIsIDIwMTcsIGF0IDE6NTIgQU0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+
IHdyb3RlOg0KPiANCj4gVGhhdCBpcyB0cnVlIGZvciByZWxhdGl2ZWx5IHNtYWxsIG1hcHMuICBJ
ZiB5b3UgZ2V0IGEgbGFyZ2UgZW5vdWdoIG1hcCB0aGVuIHRoaW5ncyBzdGFydCBnb2luZyBkb3du
IGhpbGwuDQo+IA0KPiBBbHNvLCBwYXJ0IG9mIG15IHdvcnJ5IHdhcyB0aGUgcXVlc3Rpb24gb2Yg
Z2V0dGluZyBhIGNhbm9uaWNhbGl6YXRpb24uICBJIGZpbmQgdGhpcyB0byBiZSBkaWZmaWN1bHQg
d2l0aCBtYXBzIGJ1dCBub3Qgd2l0aCBhcnJheXMuDQo+IA0KPiBKaW0NCj4gDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExhdXJlbmNlIEx1bmRibGFkZSBbbWFpbHRvOmxs
dW5kYmxhQHF0aS5xdWFsY29tbS5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDExLCAyMDE3
IDk6MTcgUE0NCj4gVG86IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQo+IENj
OiBjYm9yQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ2Jvcl0gQXBwbGljYXRpb24gc3BlY2lm
aWMgdGFnZ2luZw0KPiANCj4gTWFwcyB3aXRoIHNtYWxsIGludGVnZXIga2V5cyBhcmUgdmVyeSBj
aGVhcCBpbiBDQk9SLiBZb3UgY2Fu4oCZdCBleHByZXNzIHRoaXMgaW4gSlNPTiBlYXNpbHkuIFdv
dWxkIGJlIGhlc2l0YW50IHRvIGFkZCB0aGUgY29tcGxleGl0eSB3aXRob3V0IGEgY29tcGVsbGlu
ZyBleGFtcGxlLg0KPiANCj4gTEwNCj4gDQo+PiBPbiBKdWwgMTEsIDIwMTcsIGF0IDEyOjA0IFBN
LCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4+IA0KPj4gSSBo
YXZlIG5vdCByZWFsbHkgdGhvdWdodCB0aGlzIHRocm91Z2gsIGFuZCBJIGRvbid0IGtub3cgdGhh
dCBpdCBjYW4gDQo+PiBlYXNpbHkgYmUgaW1wbGVtZW50ZWQgaW4gc3VjaCBhIHdheSBhcyB0byBt
YWtlIGl0IHNtYWxsLg0KPj4gDQo+PiBJdCBtaWdodCBiZSBuaWNlIHRvIGRlZmluZSB0aGUgYWJp
bGl0eSBmb3IgYW4gYXBwbGljYXRpb24gc3BlY2lmaWMgDQo+PiB0YWdnaW5nIG1lY2hhbmlzbSB0
byBiZSBkZWZpbmVkLiAgV2hpbGUgdGhpcyB0byBzb21lIGV4dGVudCBjYW4gYmUgDQo+PiB0aG91
Z2h0IG9mIGFzIGR1cGxpY2F0aW5nIHRoZSBmdW5jdGlvbmFsaXR5IG9mIG1hcHMsIHdoZW4gb25l
IHdhbnRzIHRvIA0KPj4gZG8gYSBtb3JlIGNhbm9uaWNhbCBlbmNvZGluZyBpdCB3aWxsIHByb2R1
Y2Ugc21hbGxlciBkYXRhIHRoYW4gaGF2aW5nIGEga2V5IGZvciBldmVyeSBmaWVsZC4NCj4+IA0K
Pj4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZw0KPj4gDQo+PiBBcnJheV9pdGVtID0gWw0KPj4gIHZl
cnNpb246IGludCwNCj4+ICBmaWVsZDEgOiBpbnQsDQo+PiAgPyBmaWVsZDIgOiBpbnQsDQo+PiAg
ZmllbGQgMyA6IGludCwNCj4+ICA/IGZpZWxkNCA6IGludA0KPj4gXQ0KPj4gDQo+PiBBcyB3cml0
dGVuLCB3aGlsZSB0aGUgc3ludGF4IGlzIHZhbGlkIG9uZSBjYW5ub3QgZGVjaWRlIGZvciBbIDks
IDEwLCANCj4+IDExLCAxMl0gd2hpY2ggb2YgdGhlIGZpZWxkcyBhcmUgcHJlc2VudCBhbmQgd2hp
Y2ggYXJlIGFic2VudC4gIEFTTi4xIA0KPj4gc29sdmVzIHRoaXMgcHJvYmxlbSBieSB0aGUgYWJp
bGl0eSB0byBkbyB0YWdnaW5nIHNvIHRoYXQgb25lIGNhbiB3cml0ZQ0KPj4gDQo+PiBBcnJheV9p
dGVtID0gWw0KPj4gIHZlcnNpb246IGludCwNCj4+ICBmaWVsZDEgOiBpbnQsDQo+PiAgPyBbMV0g
ZmllbGQyIDogaW50LA0KPj4gIGZpZWxkIDMgOiBpbnQsDQo+PiAgPyBbMl0gZmllbGQ0IDogaW50
DQo+PiBdDQo+PiANCj4+IEFuZCBub3cgaXQgaXMgZWFzeSB0byBpZGVudGlmeSB3aGljaCBmaWVs
ZCBpcyBwcmVzZW50LiAgIA0KPj4gDQo+PiBIb3dldmVyIHRoaXMgbGVhZHMgdG8gcHJvYmxlbXMg
aW4gdHJ5aW5nIHRvIGRldGVybWluZSBob3cgdG8gYWN0dWFsbHkgDQo+PiBlbmNvZGUgaW4gQ0JP
Ui4gIFdoaWxlIHRoZSBuaWNlIHRoaW5nIHdvdWxkIGJlIHRvIGRvIHNvbWV0aGluZyBsaWtlICAN
Cj4+IFs5LCAxMCwgMTEsIDIoMTIpXSBzbyB0aGF0IHlvdSBoYXZlIGEgYSB0YWcgd2hpY2ggIGhh
cyBhcmJpdHJhcnkgY2JvciANCj4+IGFzIGEgY2hpbGQuICBUaGlzIGlzIG5vdCBjdXJyZW50bHkg
c29tZXRoaW5nIHRoYXQgY2FuIGJlIHdyaXR0ZW4uICBUaGUgDQo+PiBiZXN0IEkgY2FuIGNvbWUg
dXAgd2l0aCBhdCB0aGUgbW9tZW50IHdvdWxkIGJlIFs5LCAxMCwgMTEsIFgoWzIsIDEyXSldIA0K
Pj4gYnV0IEkgd291bGQgbGlrZSB0byBub3QgaGF2ZSB0aGUgYXJyYXkuDQo+PiANCj4+IE5vdGUg
dGhhdCB0aGlzIG1pZ2h0IGJlIGhlbHBmdWwgZm9yIHRoZSBTRU1MIHBlb3BsZSBhcyBJIHNlZW0g
dG8gDQo+PiByZW1lbWJlciBhbiBhcmd1bWVudCB3aGVyZSBhcHBsaWNhdGlvbiB0YWdnaW5nIHdh
cyBuZWVkZWQuDQo+PiANCj4+IEppbQ0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQk9SIG1haWxpbmcgbGlzdA0KPj4gQ0JP
UkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9y
DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gQ0JPUiBtYWlsaW5nIGxpc3QNCj4gQ0JPUkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0K


From nobody Wed Jul 12 10:58:36 2017
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 0988212EAF9 for ; Wed, 12 Jul 2017 10:58:34 -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 4-MP5whGuo9r for ; Wed, 12 Jul 2017 10:58:32 -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 05721127077 for ; Wed, 12 Jul 2017 10:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6CHvq3k010388; Wed, 12 Jul 2017 19:57:52 +0200 (CEST)
Received: from client-0027.vpn.uni-bremen.de (client-0027.vpn.uni-bremen.de [134.102.107.27]) (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 3x769r03GRzDK7L; Wed, 12 Jul 2017 19:57:51 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <15725A02-2F36-4CC3-98B7-4BD49F6B68BE@qti.qualcomm.com>
Date: Wed, 12 Jul 2017 19:57:51 +0200
Cc: Jim Schaad , "cbor@ietf.org" 
X-Mao-Original-Outgoing-Id: 521575070.930252-ad6808850b1255af6dd39bfbbe6f7ac5
Content-Transfer-Encoding: quoted-printable
Message-Id: <56B8C756-2906-4C75-834F-09DBF7901F9D@tzi.org>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>  <04b201d2faec$28738190$795a84b0$@augustcellars.com> <15725A02-2F36-4CC3-98B7-4BD49F6B68BE@qti.qualcomm.com>
To: Laurence Lundblade 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 17:58:34 -0000

On Jul 12, 2017, at 19:24, Laurence Lundblade =
 wrote:
>=20
> What is the issue with canonicalization of maps?  I can=E2=80=99t =
think of what it is, but hopefully it is just mildly inconvenient, not =
actually difficult.

Traditionally, the problem is that people get it wrong.  (So we tried to =
define it well.  And to make the definition simple enough that it is not =
that easy to get wrong.  See below :-)

It is also slightly inconvenient, as you cannot generate the map on the =
fly, but need to wait with outputting bytes until you have all fields =
(well, at least all the keys).

We have aggravated this a bit by defining map ordering in such a way in =
Section 3.9 that it violates the POLS (principle of least surprise) for =
at least some implementers.  Discussion ongoing in another thread=E2=80=A6=


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


From nobody Wed Jul 12 12:03:03 2017
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 10DD512EB13 for ; Wed, 12 Jul 2017 12:03:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 cZ8IuiO0dmmK for ; Wed, 12 Jul 2017 12:02:59 -0700 (PDT)
Received: from alexa-out-lv-01.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A8D129432 for ; Wed, 12 Jul 2017 12:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1499886179; x=1531422179; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K9pUXFi3L/vTJwNR15ZqHcVxcJbxBD3AhKxjY2dAPSQ=; b=c+WvWEJ83lR/UCv8KZjWqcvLY/hF507aT8VCZjxwsryW913aLMTinIq1 2BbW5gOoFYSIuqnqMwPpWYmA4o0R8DqEUF+4mORURmmjfxVHgjSUyV0VC b4xArOeCrpMd0lVoDqiubMxzf8s7eWlU1JBKAAAROwZLjNkiMby+a9c3Q U=;
X-IronPort-AV: E=Sophos;i="5.40,351,1496127600";  d="scan'208";a="831991"
Received: from ironmsg02-l-new.qualcomm.com (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by alexa-out-lv-01.qualcomm.com with ESMTP; 12 Jul 2017 12:02:59 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8589"; a="963592644"
X-MGA-submission: =?us-ascii?q?MDH7rpIUyjsZa5VhOInh+/H36LNJ6Xxc6gD2Tu?= =?us-ascii?q?PHFhgb3tNtavoxaTaZBITI7VHMesLCzg4S9y7F/golCvcr9rG2KSYVsk?= =?us-ascii?q?dAsAHJJ7HJyaLeZc+aBYi1mg2eJJKFaFJnNeeupZ5VHq0NCs78+2sfbC?= =?us-ascii?q?j1?=
Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Jul 2017 12:02:58 -0700
Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 12 Jul 2017 12:02:58 -0700
Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Wed, 12 Jul 2017 12:02:58 -0700
From: Laurence Lundblade 
To: Carsten Bormann 
CC: Jim Schaad , "cbor@ietf.org" 
Thread-Topic: [Cbor] Application specific tagging
Thread-Index: AdL6caAX+6csORz9R8mq25LivXKLyQAQ1YsAABx20YAAEeX2AAABKPuAAAJGCoA=
Date: Wed, 12 Jul 2017 19:02:57 +0000
Message-ID: <6D075591-0171-46BF-BC51-EAAF957CE8E2@qti.qualcomm.com>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com>  <04b201d2faec$28738190$795a84b0$@augustcellars.com> <15725A02-2F36-4CC3-98B7-4BD49F6B68BE@qti.qualcomm.com> <56B8C756-2906-4C75-834F-09DBF7901F9D@tzi.org>
In-Reply-To: <56B8C756-2906-4C75-834F-09DBF7901F9D@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Wed, 12 Jul 2017 19:03:01 -0000

T24gSnVsIDEyLCAyMDE3LCBhdCAxMDo1NyBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5v
cmc+IHdyb3RlOg0KPiANCj4gT24gSnVsIDEyLCAyMDE3LCBhdCAxOToyNCwgTGF1cmVuY2UgTHVu
ZGJsYWRlIDxsbHVuZGJsYUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4+IA0KPj4gV2hhdCBp
cyB0aGUgaXNzdWUgd2l0aCBjYW5vbmljYWxpemF0aW9uIG9mIG1hcHM/ICBJIGNhbuKAmXQgdGhp
bmsgb2Ygd2hhdCBpdCBpcywgYnV0IGhvcGVmdWxseSBpdCBpcyBqdXN0IG1pbGRseSBpbmNvbnZl
bmllbnQsIG5vdCBhY3R1YWxseSBkaWZmaWN1bHQuDQo+IC4uLg0KPiANCj4gV2UgaGF2ZSBhZ2dy
YXZhdGVkIHRoaXMgYSBiaXQgYnkgZGVmaW5pbmcgbWFwIG9yZGVyaW5nIGluIHN1Y2ggYSB3YXkg
aW4gU2VjdGlvbiAzLjkgdGhhdCBpdCB2aW9sYXRlcyB0aGUgUE9MUyAocHJpbmNpcGxlIG9mIGxl
YXN0IHN1cnByaXNlKSBmb3IgYXQgbGVhc3Qgc29tZSBpbXBsZW1lbnRlcnMuICBEaXNjdXNzaW9u
IG9uZ29pbmcgaW4gYW5vdGhlciB0aHJlYWTigKYNCg0KSSBhbSBub3cgc3VycHJpc2VkLiBDYW4g
eW91IHBvaW50IG1lIHRvIHRoZSBvdGhlciBkaXNjdXNzaW9uIHRocmVhZD8NCg0KTEw=


From nobody Sat Jul 15 21:54:44 2017
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 7B21B129ADA for ; Sat, 15 Jul 2017 21:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 zTCNxHZ2cxdd for ; Sat, 15 Jul 2017 21:54:41 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 35D1712871F for ; Sat, 15 Jul 2017 21:54:41 -0700 (PDT)
Received: from [192.168.122.105] (unknown [174.65.80.226]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A37B522E256; Sun, 16 Jul 2017 00:54:20 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Leonard 
In-Reply-To: 
Date: Sat, 15 Jul 2017 21:54:19 -0700
Cc: Jim Schaad , cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A148EBD-0989-4DDB-83CB-11DB83FF3379@seantek.com>
References: <044201d2fa78$90e45bb0$b2ad1310$@augustcellars.com> <4C9A56D3-7CE9-4FA2-BEEC-A2226EBC053E@tzi.org> <04b301d2faec$3e6d44e0$bb47cea0$@augustcellars.com> 
To: Paul Hoffman 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Application specific tagging
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: Sun, 16 Jul 2017 04:54:42 -0000

> On Jul 12, 2017, at 7:43 AM, Paul Hoffman  =
wrote:
>=20
> On 12 Jul 2017, at 1:52, Jim Schaad wrote:
>=20
>> Yes, that is how I have done it today in the COSE spec.  However, I =
think it might be a useful feature to kick around and see if it can be =
done.
>=20
> I respectfully disagree. Its use in ASN.1 has always been problematic =
for data designers, and I think we had some problems with some proposed =
CMS specs that only got caught late in the process.
>=20
> A better design rule is "if you have optional fields, it's an =
object=E2=80=9D.

I agree with Paul on this one.

It appears from RFC 7049 that CBOR tags are =E2=80=9Cuniversal=E2=80=9D: =
once a tag is registered, it is supposed to have that same meaning =
across all CBOR specs for all time. Tag numbers are supposed to be =
cheap, at least beyond the 1-byte range. There is congestion in the =
1-byte range but there is pretty much no congestion in the 2-byte range, =
and the 4-byte range is pretty much inexhaustible.

I do not see a problem with having duplicate tag registrations, where a =
tag that was originally very application-specific (and assigned a high =
tag number, e.g., 99999999) now appears more useful and to save space on =
the wire, it is doubly-assigned to a low number (99 or some such). But =
that is a philosophical issue that has not been debated extensively in =
CBOR as far as I know.

If you want something that is specific to your application, make it a =
key in a map, or make it implicit in the index of the array. You can =
always put a one-byte CBOR item in an array as a pad, namely the simple =
values false, true, null, and undefined.

Sean


From nobody Tue Jul 18 02:22:59 2017
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 6CA0C131DC5 for ; Tue, 18 Jul 2017 02:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aocgXSaBVfsQ for ; Tue, 18 Jul 2017 02:22:55 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E93F131A67 for ; Tue, 18 Jul 2017 02:22:55 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id d78so4569575lfg.3 for ; Tue, 18 Jul 2017 02:22:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=9SyCIvoGd/nIMkxZDLLIsNoHc934rOXnBkx6ASdP4Xg=; b=xlVZlw/YNtUynkOU/9thTH1rL50p6YInPsuUo8ZfFgbqz0fLbMh16ydAjtl1HHXR8c eQ0rtTKxHS/C4y2xuhGcpQCBQIyukFNOVl5ey+8vRUK8AlilualdOAU9uHS+Nj2hLE1U 6q1DXY1EnBCH/VMbV89UeFK+l4B+Xr2Qo6yQgpkn6tDq+eeVGlJjqpGVeHRLSCHpGQEa F7nAy4/oD9ZriJKPB8m8Mi4S00z8YNrW6tbMgAQU6OjvnOk6MMphNaH22iQtwzTynDF3 7z/eG8cYTZSsZi+sPpzVOSrq/h3mDEa+conKjzr/ycVQdz1YifWvWd7beoJQ+PyM8iXB 1D8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=9SyCIvoGd/nIMkxZDLLIsNoHc934rOXnBkx6ASdP4Xg=; b=qqZnq1NI8bW8MR3w1OVjCYMUkepXnAwXgUdB2OQIeSXDLtdhz6wV3Tcf6+mACCix6h Ectxdm5Iu8yxrY/V5fKdPbRuujjJbHyWT8+bweQEL5NqOv9htb5KOo8bBqRGy1Vps9tn ZAXpNMyGjEQTze5hiB8TQsMxKHZgaX5pLYCFvsjq3qLcPoMNTdwg5cOl8ymyLPsRnrdv dz0YnSiTVB7A00mlpFiSwu14aHQIa1/VSEH2wJLELx5qZnkDUnOezkyo4TPieoDvWpU3 cvs4kDdiDI/JQ/UFGKuelfGQ25EvngyY8/gtSZ4KqdhvfpxK2AiAt6ehB0ON9RhKES7c gjVw==
X-Gm-Message-State: AIVw113yl0lKGjHYNMb2i+KiOj/nOQQL3U7cMdTD8kdCF4jphvps1Ts/ mnmOJOrBQN0NKDurexZk4g==
X-Received: by 10.80.151.219 with SMTP id f27mr1164309edb.126.1500369773541; Tue, 18 Jul 2017 02:22:53 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:94a2:4c24:1711:bf? ([2001:67c:370:128:94a2:4c24:1711:bf]) by smtp.gmail.com with ESMTPSA id f48sm1465035edf.30.2017.07.18.02.22.52 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 02:22:52 -0700 (PDT)
To: cbor@ietf.org
References: 
From: "Matthew A. Miller" 
Message-ID: <4de102ae-44b6-3361-9866-bf6674da90ff@outer-planes.net>
Date: Tue, 18 Jul 2017 11:22:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Thunderbird/54.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DgslEF5aDlwEG8se5O7ckgtK5Fb8EHaot"
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Tue, 18 Jul 2017 09:22:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DgslEF5aDlwEG8se5O7ckgtK5Fb8EHaot
Content-Type: multipart/mixed; boundary="WSHg5VOaVVOanwcLkqKeObvMUBr91qix2";
 protected-headers="v1"
From: "Matthew A. Miller" 
To: cbor@ietf.org
Message-ID: <4de102ae-44b6-3361-9866-bf6674da90ff@outer-planes.net>
Subject: =?UTF-8?Q?Re:_[Cbor]_=f0=9f=94=94_Confirmation_call_for_Working_Gro?=
 =?UTF-8?Q?up_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
References: 
In-Reply-To: 

--WSHg5VOaVVOanwcLkqKeObvMUBr91qix2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 7/5/17 11:48 AM, Francesca Palombini wrote:
> Hi all,
>=20
> =20
>=20
> At the IETF98 meeting, we had in-room consensus to adopt
> draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBO=
R
> data definition language. The authors have now updated the document and=

> feel this is ready to be a wg item.
>=20
> =20
>=20
> This is a confirmation call for adopting this draft as a working group
> item. If you do not agree with the in-room consensus that we had in
> Chicago to adopt this as a WG document, please speak up until
> 2017-07-19. If you weren=E2=80=99t in the room but do agree with adopti=
ng this
> document, you can also tell us.
>=20
> =20
>=20
> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11

I re-iterate my support for adopting this draft as a working group item.

I also support moving this document to the Standards Track.


- m&m

Matthew A. Miller
< http://goo.gl/LM55L >



--WSHg5VOaVVOanwcLkqKeObvMUBr91qix2--

--DgslEF5aDlwEG8se5O7ckgtK5Fb8EHaot
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZbdNrAAoJEOz0ck4QngW7N08H/0kyWv8+av8ZrhkiZqdaGe2R
sxbhllGvG4gfAwO64aJynqp9lGXh/TIC0TKp0U3RFri6Z+QYxuzOHB9XEzKdGmZR
sqebmb1UNit1kFTsAihKjJRZVBtS1+ijeSYhaK+PoeGIswV6cih1/P2zDXYc4f8Y
0wt0jQI/mOfum62QEOck4RpITXmgzM3DWNIJD31QMUQAtIwGlsdUGUrOJZmYBZL3
yDL6bKdMYGlD9VBeHTielj4B5pze82ZQsy5wRhBIx2rcTHYbeeanVPupNqltFlU2
EHcESR8H9zOPq6kQ9J8tXgbRVDDsseDlfIDLZM21AS0OJnYuUPp518u29rKNzKg=
=QlcO
-----END PGP SIGNATURE-----

--DgslEF5aDlwEG8se5O7ckgtK5Fb8EHaot--


From nobody Tue Jul 18 02:29:26 2017
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 86ECD131DDE for ; Tue, 18 Jul 2017 02:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 fMut1IihNoan for ; Tue, 18 Jul 2017 02:29:22 -0700 (PDT)
Received: from out0-236.mail.aliyun.com (out0-236.mail.aliyun.com [140.205.0.236]) by ietfa.amsl.com (Postfix) with ESMTP id 99F5D126E3A for ; Tue, 18 Jul 2017 02:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1500370154; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=LFkc6ax+fsPVQ9TngoBejZBRs3Y4/22eMziFBPbVeiU=; b=Hv1yfkeNfcUDnQgVL0k1itQlplrVkRaOoh4+LHDTxJo5XJ4VOb1C42NWS5ld72lYLaiOqAT+xc/TFxDrdZEyIb8ihF0zQUazzZDKigH5nTXgWNXZPz6I/d0Z5VA0Cym7lmYI2ONN1Gtq7NxCf8GTnYhaNfsIl/kz8UCuKjykxv0=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03297; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_---.8REDVyk_1500370147; 
Received: from 30.27.110.15(mailfrom:kepeng.lkp@alibaba-inc.com ip:106.11.34.20) by smtp.aliyun-inc.com(127.0.0.1); Tue, 18 Jul 2017 17:29:11 +0800
User-Agent: Microsoft-MacOutlook/14.6.8.160830
Date: Tue, 18 Jul 2017 17:29:06 +0800
From: "Kepeng Li" 
To: "Matthew A. Miller" , 
Message-ID: 
Thread-Topic: [Cbor] =?UTF-8?B?8J+UlA==?= Confirmation call for Working Group Adoption for draft-greevenbosch-appsawg-cbor-cddl
References:  <4de102ae-44b6-3361-9866-bf6674da90ff@outer-planes.net>
In-Reply-To: <4de102ae-44b6-3361-9866-bf6674da90ff@outer-planes.net>
Mime-version: 1.0
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Tue, 18 Jul 2017 09:29:24 -0000

I support for adopting this draft as a working group item.


Kind Regards
Kepeng

=D4=DA 18/07/2017, 5:22 PM=A3=AC "CBOR on behalf of Matthew A. Miller"
 =D0=B4=C8=EB:

>On 7/5/17 11:48 AM, Francesca Palombini wrote:
>> Hi all,
>>=20
>> =20
>>=20
>> At the IETF98 meeting, we had in-room consensus to adopt
>> draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR
>> data definition language. The authors have now updated the document and
>> feel this is ready to be a wg item.
>>=20
>> =20
>>=20
>> This is a confirmation call for adopting this draft as a working group
>> item. If you do not agree with the in-room consensus that we had in
>> Chicago to adopt this as a WG document, please speak up until
>> 2017-07-19. If you weren=A1=AFt in the room but do agree with adopting this
>> document, you can also tell us.
>>=20
>> =20
>>=20
>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11
>
>I re-iterate my support for adopting this draft as a working group item.
>
>I also support moving this document to the Standards Track.
>
>
>- m&m
>
>Matthew A. Miller
>< http://goo.gl/LM55L >
>
>
>_______________________________________________
>CBOR mailing list
>CBOR@ietf.org
>https://www.ietf.org/mailman/listinfo/cbor



From nobody Tue Jul 18 06:17:31 2017
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 0459712EC05 for ; Mon, 17 Jul 2017 20:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UiHhF3M5m0f for ; Mon, 17 Jul 2017 20:57:21 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CF4127866 for ; Mon, 17 Jul 2017 20:57:21 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id h199so3020472ith.0 for ; Mon, 17 Jul 2017 20:57:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Jo+MqjDoH2ZDg8ORxcELP2RXH1w9x2OCb25KcboS+uU=; b=YkppGmqXwGSOW4T3LKile3fLF0hnfyVXRlMc//l3qz0EwMhEySituROeSP8HGyzwIf dv09qYXj7RYdR+pGkRQOtZjV4ucpJsmKKUVVLtvLUcZdkSo4XFfHLGOUCmYUIJWcEKFA za0vGbj41eNHaVc+w107AJbIth4/Xz1ewYzOs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Jo+MqjDoH2ZDg8ORxcELP2RXH1w9x2OCb25KcboS+uU=; b=sGsv+To9PwO5YJ8GYo8NdrIXqwhadZiHMDg1soUmfx4bMMbsvMW8uOtVjU6sN6SIgo +JsEVt9eIGwovf2Cxbo6mZfjyUEvZ8mzR8BxDS5raP4UXsPOuukZVr/2DqywQm/Rztqm lanzYy3i/AFQihrYj9aGjJ8Hr+ckeeazBPpGW3ea0TFgSD75qTj+EpNL0ZRJzTpy4SZY NoGxw3jbA3HvW7ep9OHPjGYW05kOznwfE2cPnEdqtgmSemnuGMjZXHTs1hXPulGURNXY dpUVFZ4r3glcrmOEUkYyMbBFKMwVRZ5sbOfyXjktYLzeMbXjGqawUMjnzzKchvlsxwbC ER0w==
X-Gm-Message-State: AIVw110878hLFgOKI/cyif7H2eClngZ21BR/U56JysDsZah4OYYqPNm7 bprhOB8aPPRQoQtjBsjRXQ==
X-Received: by 10.36.58.72 with SMTP id m69mr633556itm.25.1500350240181; Mon, 17 Jul 2017 20:57:20 -0700 (PDT)
Received: from ?IPv6:2601:282:200:be4d:bdd3:395f:b792:9942? ([2601:282:200:be4d:bdd3:395f:b792:9942]) by smtp.gmail.com with ESMTPSA id c4sm652646ioc.18.2017.07.17.20.57.19 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 20:57:19 -0700 (PDT)
From: Joe Hildebrand 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <7DB04C3B-A3BD-4DF4-B8EF-0B4454E139AA@mozilla.com>
Date: Mon, 17 Jul 2017 21:57:18 -0600
To: "cbor@ietf.org" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-Mailman-Approved-At: Tue, 18 Jul 2017 06:17:30 -0700
Subject: [Cbor] Implementation Matrix for node-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: Tue, 18 Jul 2017 03:57:23 -0000

I filled in =
https://github.com/cbor-wg/CBORbis/wiki/Implementation-matrix with info =
from node-cbor, distinguishing what could be decoded and encoded.

The code (and sample data) is here:
=
https://github.com/hildjj/node-cbor/blob/master/test/implementation_matrix=
.js

in case anyone wants to use the same inputs.

=E2=80=94=20
Joe Hildebrand


From nobody Tue Jul 18 11:43:11 2017
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 8B0BA131BCA for ; Tue, 18 Jul 2017 11:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 MtQRDyose7G8 for ; Tue, 18 Jul 2017 11:43:08 -0700 (PDT)
Received: from server.obj-sys.com (server.obj-sys.com [74.50.121.244]) (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 C2923126DC2 for ; Tue, 18 Jul 2017 11:43:06 -0700 (PDT)
Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:51794 helo=[10.0.0.100]) by server.obj-sys.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dXXSb-0002av-QD for cbor@ietf.org; Tue, 18 Jul 2017 14:43:05 -0400
From: Kevin Braun 
To: cbor@ietf.org
Message-ID: 
Date: Tue, 18 Jul 2017 14:43:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Antivirus: Avast (VPS 170718-2, 07/18/2017), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.obj-sys.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - obj-sys.com
X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: kbraun@obj-sys.com
X-Authenticated-Sender: server.obj-sys.com: kbraun@obj-sys.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: [Cbor] Validation of maps
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: Tue, 18 Jul 2017 18:43:09 -0000

Hi,

I know the question of more formally specifying validation rules already 
came up.  One would think map validation would be fairly obvious, but 
what happens when key types overlap?

For example, I think the intention is that if you have

    top = { 4 => int, *int => tstr }

then the key 4 must be present with an integer value, and you can have 
any number of other integer keys with text string values. Okay, but what 
about:

top = { ? 4 => int, *int => tstr }

We might say this means that if a key of 4 appears, then it must have an 
int value.  Or, does it allow a key of 4 to appear with a text string 
value while considering the optional "4 => int" as being absent?  Given 
the examples in the spec, I guess the intention is for such a thing to 
mean the key 4, if present, has to have an int value.  So, there is some 
kind of "match the most specific key" rule implied (I guess).  How that 
rule applies in more complex situations (where there is some kind of 
nesting) probably needs to be spelled out....  Given:

    top = { 1 => 1, ? ( 5 => 5, 6 => 6 ), *int => tstr }

Must keys 5 & 6 be present together, or does the wildcard allow only one 
of them to appear?  Or, given:

    top = { 1 => 1, ( 5 => 5 // 6 => 6 ), *int => tstr }

does this mean { 1 : 1, 5 : 5, 6 : "hi" }  is not valid?  Is the 6 free 
to match the wildcard when the 5 has satisfied the group choice?

Then there are cases where "most specific key" has no meaning, such as 
when two key types overlap each other and neither is a single-value 
type.  Consider:

    top = { * (0..10) => tstr, * (5..15) => int }

Does this mean a key of 5 can have either a text string or an int 
value?  Or, does it require that a key of 5, if present, must have a 
value that is both a text string and an int at the same time (i.e. it 
disallows 5 to appear)?

Regards,
Kevin


From nobody Tue Jul 18 14:19:09 2017
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 6562E131683 for ; Tue, 18 Jul 2017 14:19:07 -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 j88hrw_pKLMc for ; Tue, 18 Jul 2017 14:19:06 -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 A9A4112F29A for ; Tue, 18 Jul 2017 14:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6ILJ1Mo012897; Tue, 18 Jul 2017 23:19:01 +0200 (CEST)
Received: from surfer-172-30-2-218-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (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 3xBtM93fX4z3b1B; Tue, 18 Jul 2017 23:19:01 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 18 Jul 2017 23:18:55 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 522105535.466722-9ba1e466f286069765c78733b1c8c9df
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>
References: 
To: Kevin Braun 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Validation of maps
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: Tue, 18 Jul 2017 21:19:07 -0000

Hi Kevin,

> I know the question of more formally specifying validation rules =
already came up.  One would think map validation would be fairly =
obvious, but what happens when key types overlap?
>=20
> For example, I think the intention is that if you have
>=20
>   top =3D { 4 =3D> int, *int =3D> tstr }
>=20
> then the key 4 must be present with an integer value,

Right, that is the only way to match the first field.
(And there is no way to have that as well as another /4/ key with a text =
string value.)

> and you can have any number of other integer keys with text string =
values. Okay, but what about:
>=20
> top =3D { ? 4 =3D> int, *int =3D> tstr }
>=20
> We might say this means that if a key of 4 appears, then it must have =
an int value.  Or, does it allow a key of 4 to appear with a text string =
value while considering the optional "4 =3D> int" as being absent? =20

Yes, that is the semantics.  It is not always what a specifier might =
intend.

The reason is that the map opens a choice point.  A member with key 4 is =
starting to match the field.  If the value however does not  match =
(because there is no int), the matcher falls back to the choice point.  =
It then tries the other field, and indeed, that matches.

In the research underlying CDDL, we have discussed =E2=80=9Ccuts=E2=80=9D =
(a concept from error handling in Parse Expression Grammars (PEGs)) as =
the solution to this.  If ^ represents a cut, write:

top =3D { ? 4 ^ =3D> int, *int =3D> tstr }

Once the 4 matches, there is no way back; for this member, another match =
is no longer tried.
A nice side effect is that anything except an int after a key of 4 can =
give a definite error message of =E2=80=9Cint expected=E2=80=9D.
The cut proposal includes : as an abbreviation for ^=3D>, so you can =
simply write:

top =3D { ? 4: int, *int =3D> tstr }

> Given the examples in the spec, I guess the intention is for such a =
thing to mean the key 4, if present, has to have an int value.

Which example leads you to this conclusion?

>  So, there is some kind of "match the most specific key" rule implied =
(I guess). =20

Actually, the PEG semantics we have borrowed here is that the *first* =
match is used.  But only rules are matched that indeed match!

> How that rule applies in more complex situations (where there is some =
kind of nesting) probably needs to be spelled out....  Given:
>=20
>   top =3D { 1 =3D> 1, ? ( 5 =3D> 5, 6 =3D> 6 ), *int =3D> tstr }
>=20
> Must keys 5 & 6 be present together,

Yes.

The whole group in the parentheses is optional.

> or does the wildcard allow only one of them to appear? =20

(That was an early semantics we tried, and it leads down the drain.
It is much better to have a matcher that simply and stupidly follows =
what=E2=80=99s in the grammar.)

> Or, given:
>=20
>   top =3D { 1 =3D> 1, ( 5 =3D> 5 // 6 =3D> 6 ), *int =3D> tstr }
>=20
> does this mean { 1 : 1, 5 : 5, 6 : "hi" }  is not valid? =20

No.  The first field eats the 1: 1, the second field only matches the 5: =
5, so the third field gets to eat zero or more int: tstr, of which 6: =
=E2=80=9Chi=E2=80=9D is a match.

> Is the 6 free to match the wildcard when the 5 has satisfied the group =
choice?

Yes.

>=20
> Then there are cases where "most specific key" has no meaning,

(Again, we use =E2=80=9Cfirst match=E2=80=9D.)

> such as when two key types overlap each other and neither is a =
single-value type.  Consider:
>=20
>   top =3D { * (0..10) =3D> tstr, * (5..15) =3D> int }
>=20
> Does this mean a key of 5 can have either a text string or an int =
value? =20

As long as there are no cuts here, yes.

> Or, does it require that a key of 5, if present, must have a value =
that is both a text string and an int at the same time (i.e. it =
disallows 5 to appear)?

That would never be the semantics =E2=80=94 the fact that there are two =
branches in a choice that can be fulfilled is not an error.

With a cut like this:

top =3D { * (0..10) ^ =3D> tstr, * (5..15) =3D> int }

this could mean that key 0..10 cut the choice and therefore need to have =
a text string value, while the rest, 11..15 can be integers, because the =
choice is cut after matching 0..10.

So far, we haven=E2=80=99t seen a use case that actually needed the cut, =
but it is still nice to have that error message.
(We also haven=E2=80=99t implemented it yet, although we will certainly =
do that over time.)

Another example where a cut helps:

message =3D orderbeer / orderwine

orderbeer =3D {
  type: =E2=80=9Cbeer=E2=80=9D,
  ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,
}

orderwine =3D {
  type: =E2=80=9Cwine=E2=80=9D,
  color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.
}

If you feed {=E2=80=9Ctype=E2=80=9D: =E2=80=9Cwine=E2=80=9D, =
=E2=80=9Cferment=E2=80=9D: =E2=80=9Ctop=E2=80=9D} into this, you get a =
rather unspecific error message that tells you things don=E2=80=99t =
match up =E2=80=94 the matcher can=E2=80=99t really know whether the =
=E2=80=9Ctype=E2=80=9D value of =E2=80=9Cwine" or the =E2=80=9Cferment=E2=80=
=9D key is the =E2=80=9Ccause=E2=80=9D of neither branch matching.

If you add a cut:

message =3D orderbeer / orderwine

orderbeer =3D {
  type: =E2=80=9Cbeer=E2=80=9D ^,
  ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,
}

orderwine =3D {
  type: =E2=80=9Cwine=E2=80=9D ^,
  color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.
}

the matcher can tell you right away that the key =E2=80=9Cferment=E2=80=9D=
 is not allowed in an orderwine message.

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


From nobody Wed Jul 19 08:10:51 2017
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 C415013192B for ; Wed, 19 Jul 2017 08:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 F-5khUeW7kwj for ; Wed, 19 Jul 2017 08:10:49 -0700 (PDT)
Received: from server.obj-sys.com (server.obj-sys.com [74.50.121.244]) (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 5501B129B15 for ; Wed, 19 Jul 2017 08:10:49 -0700 (PDT)
Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:59104 helo=[10.0.0.100]) by server.obj-sys.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dXqch-0005oQ-K0; Wed, 19 Jul 2017 11:10:48 -0400
To: Carsten Bormann 
Cc: cbor@ietf.org
References:  <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>
From: Kevin Braun 
Message-ID: 
Date: Wed, 19 Jul 2017 11:10:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Antivirus: Avast (VPS 170719-4, 07/19/2017), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.obj-sys.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - obj-sys.com
X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: kbraun@obj-sys.com
X-Authenticated-Sender: server.obj-sys.com: kbraun@obj-sys.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Cbor] Validation of maps
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: Wed, 19 Jul 2017 15:10:51 -0000

Hi Carsten,

Thanks for the explanations.

So,
     top = { ? 4 => int, *int => tstr }
matches
     { 4 : "okay" }

That surprises me because of the extensibility example:
     PersonalData = {
         ? displayName: tstr,
         NameComponents,
         ? age: uint,
         * tstr => any
     }

I interpreted the extension to allow other keys (other than 
"displayName", "age", and the keys from NameComponents) to appear, but 
not to allow the existing keys to appear with other value types.  (If 
the example is using cuts by using the colon, I didn't realize it; I 
don't think draft -11 says anything about that).  It seems I had the 
wrong idea of extensibility.  I also had a slightly wrong mental model 
for map validation in that I was thinking in terms of "this says that 
this key must have this type", which isn't quite accurate.  Though, I 
would say the example suggests the reading I gave to it, because after 
all what is the point of having "? displayName : tstr" in there if the 
"displayName" key can actually appear with any type of value at all, due 
to the "* tstr => any"?  (I'm still assuming that displayName: tstr is 
the same as "displayName" => tstr - that I wasn't supposed to read the 
example with cuts in mind and the colon being shorthand for a cut.)

I think I understand better now, except this one thing...  I don't 
understand why
    top = { ? 4 => int, *int => tstr }
matches
     { 4 : "okay" }
but
     top = { 1 => 1, ? ( 5 => 5, 6 => 6 ), *int => tstr }
does not match
     { 1 : 1, 6: "hi" }

6 : "hi" does not (alone or with anything else for that matter) match 
the optional group, but it does match the *int => tstr.  It seems 
inconsistent with how the key of 4 is handled in the first example.  
Perhaps there is some rule here that just hasn't been stated yet.

Regards,
Kevin

On 7/18/2017 5:18 PM, Carsten Bormann wrote:
> Hi Kevin,
>
>> I know the question of more formally specifying validation rules already came up.  One would think map validation would be fairly obvious, but what happens when key types overlap?
>>
>> For example, I think the intention is that if you have
>>
>>    top = { 4 => int, *int => tstr }
>>
>> then the key 4 must be present with an integer value,
> Right, that is the only way to match the first field.
> (And there is no way to have that as well as another /4/ key with a text string value.)
>
>> and you can have any number of other integer keys with text string values. Okay, but what about:
>>
>> top = { ? 4 => int, *int => tstr }
>>
>> We might say this means that if a key of 4 appears, then it must have an int value.  Or, does it allow a key of 4 to appear with a text string value while considering the optional "4 => int" as being absent?
> Yes, that is the semantics.  It is not always what a specifier might intend.
>
> The reason is that the map opens a choice point.  A member with key 4 is starting to match the field.  If the value however does not  match (because there is no int), the matcher falls back to the choice point.  It then tries the other field, and indeed, that matches.
>
> In the research underlying CDDL, we have discussed “cuts” (a concept from error handling in Parse Expression Grammars (PEGs)) as the solution to this.  If ^ represents a cut, write:
>
> top = { ? 4 ^ => int, *int => tstr }
>
> Once the 4 matches, there is no way back; for this member, another match is no longer tried.
> A nice side effect is that anything except an int after a key of 4 can give a definite error message of “int expected”.
> The cut proposal includes : as an abbreviation for ^=>, so you can simply write:
>
> top = { ? 4: int, *int => tstr }
>
>> Given the examples in the spec, I guess the intention is for such a thing to mean the key 4, if present, has to have an int value.
> Which example leads you to this conclusion?
>
>>   So, there is some kind of "match the most specific key" rule implied (I guess).
> Actually, the PEG semantics we have borrowed here is that the *first* match is used.  But only rules are matched that indeed match!
>
>> How that rule applies in more complex situations (where there is some kind of nesting) probably needs to be spelled out....  Given:
>>
>>    top = { 1 => 1, ? ( 5 => 5, 6 => 6 ), *int => tstr }
>>
>> Must keys 5 & 6 be present together,
> Yes.
>
> The whole group in the parentheses is optional.
>
>> or does the wildcard allow only one of them to appear?
> (That was an early semantics we tried, and it leads down the drain.
> It is much better to have a matcher that simply and stupidly follows what’s in the grammar.)
>
>> Or, given:
>>
>>    top = { 1 => 1, ( 5 => 5 // 6 => 6 ), *int => tstr }
>>
>> does this mean { 1 : 1, 5 : 5, 6 : "hi" }  is not valid?
> No.  The first field eats the 1: 1, the second field only matches the 5: 5, so the third field gets to eat zero or more int: tstr, of which 6: “hi” is a match.
>
>> Is the 6 free to match the wildcard when the 5 has satisfied the group choice?
> Yes.
>
>> Then there are cases where "most specific key" has no meaning,
> (Again, we use “first match”.)
>
>> such as when two key types overlap each other and neither is a single-value type.  Consider:
>>
>>    top = { * (0..10) => tstr, * (5..15) => int }
>>
>> Does this mean a key of 5 can have either a text string or an int value?
> As long as there are no cuts here, yes.
>
>> Or, does it require that a key of 5, if present, must have a value that is both a text string and an int at the same time (i.e. it disallows 5 to appear)?
> That would never be the semantics — the fact that there are two branches in a choice that can be fulfilled is not an error.
>
> With a cut like this:
>
> top = { * (0..10) ^ => tstr, * (5..15) => int }
>
> this could mean that key 0..10 cut the choice and therefore need to have a text string value, while the rest, 11..15 can be integers, because the choice is cut after matching 0..10.
>
> So far, we haven’t seen a use case that actually needed the cut, but it is still nice to have that error message.
> (We also haven’t implemented it yet, although we will certainly do that over time.)
>
> Another example where a cut helps:
>
> message = orderbeer / orderwine
>
> orderbeer = {
>    type: “beer”,
>    ferment: “bottom” / “top”,
> }
>
> orderwine = {
>    type: “wine”,
>    color: “red” / “white”.
> }
>
> If you feed {“type”: “wine”, “ferment”: “top”} into this, you get a rather unspecific error message that tells you things don’t match up — the matcher can’t really know whether the “type” value of “wine" or the “ferment” key is the “cause” of neither branch matching.
>
> If you add a cut:
>
> message = orderbeer / orderwine
>
> orderbeer = {
>    type: “beer” ^,
>    ferment: “bottom” / “top”,
> }
>
> orderwine = {
>    type: “wine” ^,
>    color: “red” / “white”.
> }
>
> the matcher can tell you right away that the key “ferment” is not allowed in an orderwine message.
>
> Grüße, Carsten
>
>


From nobody Wed Jul 19 08:50:16 2017
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 3806F131A50 for ; Wed, 19 Jul 2017 08:50:15 -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, SPF_HELO_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 47S_Jw3VYwwr for ; Wed, 19 Jul 2017 08:50:13 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 9B1BD12F3CB for ; Wed, 19 Jul 2017 08:50:13 -0700 (PDT)
Received: from [192.168.122.105] (unknown [174.65.80.226]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 035B522E256 for ; Wed, 19 Jul 2017 11:50:06 -0400 (EDT)
From: Sean Leonard 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C31AD8F5-51A5-4EE5-9A29-31A7469C3808"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Jul 2017 08:50:04 -0700
References: 
To: "cbor@ietf.org" 
In-Reply-To: 
Message-Id: <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Wed, 19 Jul 2017 15:50:15 -0000

--Apple-Mail=_C31AD8F5-51A5-4EE5-9A29-31A7469C3808
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

As expressed at the IETF 99 meeting, I support WG adoption of this =
draft.

At this time, I also support it being on the Informational track (its =
current track). The track can be changed later if needed.

Sean

> On Jul 5, 2017, at 2:48 AM, Francesca Palombini =
 wrote:
>=20
> Hi all,
> =20
> At the IETF98 meeting, we had in-room consensus to adopt =
draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR =
data definition language. The authors have now updated the document and =
feel this is ready to be a wg item.
> =20
> This is a confirmation call for adopting this draft as a working group =
item. If you do not agree with the in-room consensus that we had in =
Chicago to adopt this as a WG document, please speak up until =
2017-07-19. If you weren=E2=80=99t in the room but do agree with =
adopting this document, you can also tell us.
> =20
> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 =

> =20
> Thanks,
> Francesca
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor


--Apple-Mail=_C31AD8F5-51A5-4EE5-9A29-31A7469C3808
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

As expressed at the IETF 99 meeting, I support WG adoption of =
this draft.

At this =
time, I also support it being on the Informational track (its current =
track). The track can be changed later if needed.

Sean

On Jul 5, 2017, at 2:48 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:










Hi all,
 
At the IETF98 =
meeting, we had in-room consensus to adopt =
draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR =
data definition language. The authors have now updated the document and =
feel this is ready to be a wg item.
 
This is a confirmation call for adopting this draft =
as a working group item. If you do not agree with the in-room consensus =
that we had in Chicago to adopt this as a WG document, please speak up =
until 2017-07-19. If you weren=E2=80=99t in the room
 but do agree with adopting this document, you can also tell us.
 
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cdd=
l-11
 
Thanks,
Francesca 






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

=

--Apple-Mail=_C31AD8F5-51A5-4EE5-9A29-31A7469C3808--


From nobody Wed Jul 19 10:02:43 2017
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 3041E12EC14 for ; Wed, 19 Jul 2017 10:02: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 fdvRNHSJin02 for ; Wed, 19 Jul 2017 10:02:41 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC97129B14 for ; Wed, 19 Jul 2017 10:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6JH2b7B008570; Wed, 19 Jul 2017 19:02:37 +0200 (CEST)
Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (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 3xCNcs1rvPz3Ytd; Wed, 19 Jul 2017 19:02:37 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 19 Jul 2017 19:02:36 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 522176556.507125-cad7fbaf47f301b892493df60ad708db
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FF1220B-8856-4E1E-898F-77F0706EBBF1@tzi.org>
References:  <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org> 
To: Kevin Braun 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Validation of maps
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: Wed, 19 Jul 2017 17:02:42 -0000

> On Jul 19, 2017, at 17:10, Kevin Braun  wrote:
>=20
> Hi Carsten,
>=20
> Thanks for the explanations.
>=20
> So,
>    top =3D { ? 4 =3D> int, *int =3D> tstr }
> matches
>    { 4 : "okay" }
>=20
> That surprises me because of the extensibility example:
>    PersonalData =3D {
>        ? displayName: tstr,
>        NameComponents,
>        ? age: uint,
>        * tstr =3D> any
>    }
>=20
> I interpreted the extension to allow other keys (other than =
"displayName", "age", and the keys from NameComponents) to appear, but =
not to allow the existing keys to appear with other value types. =20

(Actually, that may be a valid extension in some universes, but it may =
or may *not* be what the spec writer intends here.)

> (If the example is using cuts by using the colon, I didn't realize it; =
I don't think draft -11 says anything about that). =20

Draft -11 does not have cuts.  I=E2=80=99m not yet convinced that we =
want to put cuts in at this point.
That=E2=80=99s why I think the current discussion is very useful:  It =
could help us find out whether the cases where cuts do more than just =
help with error messages are interesting enough to justify including =
them.

> It seems I had the wrong idea of extensibility.  I also had a slightly =
wrong mental model for map validation in that I was thinking in terms of =
"this says that this key must have this type", which isn't quite =
accurate.  Though, I would say the example suggests the reading I gave =
to it, because after all what is the point of having "? displayName : =
tstr" in there if the "displayName" key can actually appear with any =
type of value at all, due to the "* tstr =3D> any"?  (I'm still assuming =
that displayName: tstr is the same as "displayName" =3D> tstr - that I =
wasn't supposed to read the example with cuts in mind and the colon =
being shorthand for a cut.)
>=20
> I think I understand better now, except this one thing...  I don't =
understand why
>   top =3D { ? 4 =3D> int, *int =3D> tstr }
> matches
>    { 4 : "okay" }
> but
>    top =3D { 1 =3D> 1, ? ( 5 =3D> 5, 6 =3D> 6 ), *int =3D> tstr }
> does not match
>    { 1 : 1, 6: "hi" }
>=20
> 6 : "hi" does not (alone or with anything else for that matter) match =
the optional group, but it does match the *int =3D> tstr.

That is correct.
(I didn=E2=80=99t validate the examples in my message with a tool, sorry =
about that=E2=80=A6)

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


From nobody Wed Jul 19 12:52:15 2017
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 EAC64131B60 for ; Wed, 19 Jul 2017 12:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 fFg2ABn3G-Tq for ; Wed, 19 Jul 2017 12:52:01 -0700 (PDT)
Received: from server.obj-sys.com (server.obj-sys.com [74.50.121.244]) (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 5FE691200FC for ; Wed, 19 Jul 2017 12:52:01 -0700 (PDT)
Received: from 75-147-126-222-philadelphia.hfc.comcastbusiness.net ([75.147.126.222]:50564 helo=[10.0.0.100]) by server.obj-sys.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dXv0p-0005Yq-LR; Wed, 19 Jul 2017 15:52:00 -0400
To: Carsten Bormann 
Cc: cbor@ietf.org
References:  <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>  <5FF1220B-8856-4E1E-898F-77F0706EBBF1@tzi.org>
From: Kevin Braun 
Message-ID: 
Date: Wed, 19 Jul 2017 15:52:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <5FF1220B-8856-4E1E-898F-77F0706EBBF1@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Antivirus: Avast (VPS 170719-8, 07/19/2017), Outbound message
X-Antivirus-Status: Clean
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.obj-sys.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - obj-sys.com
X-Get-Message-Sender-Via: server.obj-sys.com: authenticated_id: kbraun@obj-sys.com
X-Authenticated-Sender: server.obj-sys.com: kbraun@obj-sys.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Cbor] Validation of maps
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: Wed, 19 Jul 2017 19:52:03 -0000

Hi Carsten,

On 7/19/2017 1:02 PM, Carsten Bormann wrote:
>> On Jul 19, 2017, at 17:10, Kevin Braun  wrote:
>>
>> Hi Carsten,
>>
>> Thanks for the explanations.
>>
>> So,
>>     top = { ? 4 => int, *int => tstr }
>> matches
>>     { 4 : "okay" }

Note that CDDL tool does not agree with the above (it does not validate 
it).  Based on what you've told me, I assume that is a bug.  Or, have I 
really misunderstood something?  I also found that CDDL tool won't 
validate { "displayName" : 5 } against the PersonalData definition below.

>>
>> That surprises me because of the extensibility example:
>>     PersonalData = {
>>         ? displayName: tstr,
>>         NameComponents,
>>         ? age: uint,
>>         * tstr => any
>>     }
>>
>> I interpreted the extension to allow other keys (other than "displayName", "age", and the keys from NameComponents) to appear, but not to allow the existing keys to appear with other value types.
> (Actually, that may be a valid extension in some universes, but it may or may *not* be what the spec writer intends here.)

I'm not quite sure what you mean by that.  I think you're just 
acknowledging that my idea of extension might be what some people would 
think of or be looking for, even though it isn't how CDDL actually works?

My thought here is that when you have a "data definition language", 
people are going to approach it like a schema language and interpret the 
above along the lines of defining fields and value types. Whereas, if 
you take the language to be a pattern language, then you start thinking 
of these things in the map definition as alternatives that your 
key-value pairs might or might not match, and then saying "displayName" 
might have any value type given the above rule makes total sense.  
Unfortunately (in my opinion), the example leads one to think in terms 
of field-definitions rather than patterns, since the pattern 
interpretation makes "? displayName : tstr" superfluous and you don't 
expect superfluous things in examples.  I hope what I'm saying makes 
sense.  (But, given the CDDL tool results I noted above, perhaps I've 
completely misunderstood.)

Regards,
Kevin

>
>> (If the example is using cuts by using the colon, I didn't realize it; I don't think draft -11 says anything about that).
> Draft -11 does not have cuts.  I’m not yet convinced that we want to put cuts in at this point.
> That’s why I think the current discussion is very useful:  It could help us find out whether the cases where cuts do more than just help with error messages are interesting enough to justify including them.
>
>> It seems I had the wrong idea of extensibility.  I also had a slightly wrong mental model for map validation in that I was thinking in terms of "this says that this key must have this type", which isn't quite accurate.  Though, I would say the example suggests the reading I gave to it, because after all what is the point of having "? displayName : tstr" in there if the "displayName" key can actually appear with any type of value at all, due to the "* tstr => any"?  (I'm still assuming that displayName: tstr is the same as "displayName" => tstr - that I wasn't supposed to read the example with cuts in mind and the colon being shorthand for a cut.)
>>
>> I think I understand better now, except this one thing...  I don't understand why
>>    top = { ? 4 => int, *int => tstr }
>> matches
>>     { 4 : "okay" }
>> but
>>     top = { 1 => 1, ? ( 5 => 5, 6 => 6 ), *int => tstr }
>> does not match
>>     { 1 : 1, 6: "hi" }
>>
>> 6 : "hi" does not (alone or with anything else for that matter) match the optional group, but it does match the *int => tstr.
> That is correct.
> (I didn’t validate the examples in my message with a tool, sorry about that…)
>
> Grüße, Carsten
>
>


From nobody Wed Jul 19 18:16:18 2017
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 D00F91272E1 for ; Wed, 19 Jul 2017 18:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=ED5Vcei6; dkim=pass (1024-bit key) header.d=chromium.org header.b=X26lsFVW
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 9mCUVWfIomRq for ; Wed, 19 Jul 2017 18:16:15 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 BCA42127868 for ; Wed, 19 Jul 2017 18:16:14 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id w191so13371141wmw.1 for ; Wed, 19 Jul 2017 18:16:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eWhM+hkgW2iplTD0HbhXJ1M/sGa8Vbal2btpHgiAX4U=; b=ED5Vcei6rQ/xWAKMy/mqJUs1nlPjxDCN4g5BiN6e53bYPOz/GQ7QEdAZpPJyJUn8Hx 5lGjyr5G/r+EkY9EnZ6EsQBb0IMVjVQ33Jh9VhiNgc9XvU7SCyXBeqLFYHyvmiXS1zGe sIrZgTNR2PUEZzkpcVtbMznHbJ4+448oPGQfL6enDPc3kY5v+SRzgyeV2RQNK2Nx0oH3 BC6V9Ir3LxS3ESGlVvzZGmuqOsVKZo6G35O7BmloRQ3CEIf6mIriO9bcw+LkP9ifoqTs zPl0iur+I7FOEHQYAT/qF6UmDDeZKCpmHOGX2DM+RUJwiF4X22LxYUC2f2P4zz5yf4uG cpoQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eWhM+hkgW2iplTD0HbhXJ1M/sGa8Vbal2btpHgiAX4U=; b=X26lsFVW1nY4rn2atX5nKoOeMH97NHcFot3Euoam/PSEYz595cuOWMPmiBd8pwut9r UjzphN0uhfpsshBTCeTbKXI/lepETW6tSHL4cyUJw8XOTHDgZj3d+Pe+sjTxgHmUeeza yvfGod2EkvNLlejzcugFUU33MFfnhVv31xb8k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eWhM+hkgW2iplTD0HbhXJ1M/sGa8Vbal2btpHgiAX4U=; b=XE5KN7YJSsnElFXPTKrXrMtOgft5z+xtJjYecPBqN5ONPzumv7DUsG23EUDMO3Pj3t JOenY6TkKiHZKLuhT51D58fkGhfXj3Dq68u1C2vD4woJh2wNi7dTlEsrcPUj9bZkRDA8 PHAomffY7epRkveCg0t0PjnSnoKhhpBl4nuuMI3sNDFlq68PXL9VMn0zA7T2XQvzca9L ixxHG3H8/kdm7+lfbeWbpRD7zs482lkOD/73/hVllMqogwuIHforCO6/BYxAw/xmBTgg 4+7pbhn7+J/jeirVIzWrW2jkkp+88OY6h+Sm8TaQ3zCC5YYXONVGR4cKrQ/DF+SD3Olg 7xAw==
X-Gm-Message-State: AIVw111Z18+GZG4nx0FXCLD9FRqYhbA7OAKNCIC9LkDTp/8Bu1Xh4m07 9uEdy1dW+5SGfQwg+9EoiHCwaoTb/QTlvnlgDA==
X-Received: by 10.28.144.211 with SMTP id s202mr480121wmd.111.1500513373097; Wed, 19 Jul 2017 18:16:13 -0700 (PDT)
MIME-Version: 1.0
Sender: jyasskin@google.com
Received: by 10.28.216.144 with HTTP; Wed, 19 Jul 2017 18:15:52 -0700 (PDT)
In-Reply-To: <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>
References:  <3FFCD42B-C1DE-43E3-A06D-608CACD55D86@tzi.org>
From: Jeffrey Yasskin 
Date: Thu, 20 Jul 2017 03:15:52 +0200
X-Google-Sender-Auth: S86k_QaQvGuGGaEfOneS9ZWsR-Q
Message-ID: 
To: Carsten Bormann 
Cc: Kevin Braun , cbor@ietf.org
Content-Type: multipart/alternative; boundary="001a11469d86961b710554b57ea5"
Archived-At: 
Subject: Re: [Cbor] Validation of maps
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, 20 Jul 2017 01:16:18 -0000

--001a11469d86961b710554b57ea5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

By the time CDDL makes it to an RFC, we should be answering questions like
this by quoting normative text from
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11#section=
-3.5,
not just pointing at examples.

Jeffrey

On Tue, Jul 18, 2017 at 11:18 PM, Carsten Bormann  wrote:

> Hi Kevin,
>
> > I know the question of more formally specifying validation rules alread=
y
> came up.  One would think map validation would be fairly obvious, but wha=
t
> happens when key types overlap?
> >
> > For example, I think the intention is that if you have
> >
> >   top =3D { 4 =3D> int, *int =3D> tstr }
> >
> > then the key 4 must be present with an integer value,
>
> Right, that is the only way to match the first field.
> (And there is no way to have that as well as another /4/ key with a text
> string value.)
>
> > and you can have any number of other integer keys with text string
> values. Okay, but what about:
> >
> > top =3D { ? 4 =3D> int, *int =3D> tstr }
> >
> > We might say this means that if a key of 4 appears, then it must have a=
n
> int value.  Or, does it allow a key of 4 to appear with a text string val=
ue
> while considering the optional "4 =3D> int" as being absent?
>
> Yes, that is the semantics.  It is not always what a specifier might
> intend.
>
> The reason is that the map opens a choice point.  A member with key 4 is
> starting to match the field.  If the value however does not  match (becau=
se
> there is no int), the matcher falls back to the choice point.  It then
> tries the other field, and indeed, that matches.
>
> In the research underlying CDDL, we have discussed =E2=80=9Ccuts=E2=80=9D=
 (a concept from
> error handling in Parse Expression Grammars (PEGs)) as the solution to
> this.  If ^ represents a cut, write:
>
> top =3D { ? 4 ^ =3D> int, *int =3D> tstr }
>
> Once the 4 matches, there is no way back; for this member, another match
> is no longer tried.
> A nice side effect is that anything except an int after a key of 4 can
> give a definite error message of =E2=80=9Cint expected=E2=80=9D.
> The cut proposal includes : as an abbreviation for ^=3D>, so you can simp=
ly
> write:
>
> top =3D { ? 4: int, *int =3D> tstr }
>
> > Given the examples in the spec, I guess the intention is for such a
> thing to mean the key 4, if present, has to have an int value.
>
> Which example leads you to this conclusion?
>
> >  So, there is some kind of "match the most specific key" rule implied (=
I
> guess).
>
> Actually, the PEG semantics we have borrowed here is that the *first*
> match is used.  But only rules are matched that indeed match!
>
> > How that rule applies in more complex situations (where there is some
> kind of nesting) probably needs to be spelled out....  Given:
> >
> >   top =3D { 1 =3D> 1, ? ( 5 =3D> 5, 6 =3D> 6 ), *int =3D> tstr }
> >
> > Must keys 5 & 6 be present together,
>
> Yes.
>
> The whole group in the parentheses is optional.
>
> > or does the wildcard allow only one of them to appear?
>
> (That was an early semantics we tried, and it leads down the drain.
> It is much better to have a matcher that simply and stupidly follows
> what=E2=80=99s in the grammar.)
>
> > Or, given:
> >
> >   top =3D { 1 =3D> 1, ( 5 =3D> 5 // 6 =3D> 6 ), *int =3D> tstr }
> >
> > does this mean { 1 : 1, 5 : 5, 6 : "hi" }  is not valid?
>
> No.  The first field eats the 1: 1, the second field only matches the 5:
> 5, so the third field gets to eat zero or more int: tstr, of which 6: =E2=
=80=9Chi=E2=80=9D
> is a match.
>
> > Is the 6 free to match the wildcard when the 5 has satisfied the group
> choice?
>
> Yes.
>
> >
> > Then there are cases where "most specific key" has no meaning,
>
> (Again, we use =E2=80=9Cfirst match=E2=80=9D.)
>
> > such as when two key types overlap each other and neither is a
> single-value type.  Consider:
> >
> >   top =3D { * (0..10) =3D> tstr, * (5..15) =3D> int }
> >
> > Does this mean a key of 5 can have either a text string or an int value=
?
>
> As long as there are no cuts here, yes.
>
> > Or, does it require that a key of 5, if present, must have a value that
> is both a text string and an int at the same time (i.e. it disallows 5 to
> appear)?
>
> That would never be the semantics =E2=80=94 the fact that there are two b=
ranches
> in a choice that can be fulfilled is not an error.
>
> With a cut like this:
>
> top =3D { * (0..10) ^ =3D> tstr, * (5..15) =3D> int }
>
> this could mean that key 0..10 cut the choice and therefore need to have =
a
> text string value, while the rest, 11..15 can be integers, because the
> choice is cut after matching 0..10.
>
> So far, we haven=E2=80=99t seen a use case that actually needed the cut, =
but it is
> still nice to have that error message.
> (We also haven=E2=80=99t implemented it yet, although we will certainly d=
o that
> over time.)
>
> Another example where a cut helps:
>
> message =3D orderbeer / orderwine
>
> orderbeer =3D {
>   type: =E2=80=9Cbeer=E2=80=9D,
>   ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,
> }
>
> orderwine =3D {
>   type: =E2=80=9Cwine=E2=80=9D,
>   color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.
> }
>
> If you feed {=E2=80=9Ctype=E2=80=9D: =E2=80=9Cwine=E2=80=9D, =E2=80=9Cfer=
ment=E2=80=9D: =E2=80=9Ctop=E2=80=9D} into this, you get a rather
> unspecific error message that tells you things don=E2=80=99t match up =E2=
=80=94 the matcher
> can=E2=80=99t really know whether the =E2=80=9Ctype=E2=80=9D value of =E2=
=80=9Cwine" or the =E2=80=9Cferment=E2=80=9D key
> is the =E2=80=9Ccause=E2=80=9D of neither branch matching.
>
> If you add a cut:
>
> message =3D orderbeer / orderwine
>
> orderbeer =3D {
>   type: =E2=80=9Cbeer=E2=80=9D ^,
>   ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,
> }
>
> orderwine =3D {
>   type: =E2=80=9Cwine=E2=80=9D ^,
>   color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.
> }
>
> the matcher can tell you right away that the key =E2=80=9Cferment=E2=80=
=9D is not allowed
> in an orderwine message.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>

--001a11469d86961b710554b57ea5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


By the time CDDL makes it to an RFC, we should be answerin=
g questions like this by quoting normative text from=C2=A0=
https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11#section=
-3.5, not just pointing at examples.

Jeffrey

On Tue, Jul 1=
8, 2017 at 11:18 PM, Carsten Bormann <cabo@tzi.org> wrote:
Hi Kevin,



> I know the question of more formally specifying validation rules alrea=
dy came up.=C2=A0 One would think map validation would be fairly obvious, b=
ut what happens when key types overlap?

>

> For example, I think the intention is that if you have

>

>=C2=A0 =C2=A0top =3D { 4 =3D> int, *int =3D> tstr }

>

> then the key 4 must be present with an integer value,



Right, that is the only way to match the first field.

(And there is no way to have that as well as another /4/ key with a text st=
ring value.)



> and you can have any number of other integer keys with text string val=
ues. Okay, but what about:

>

> top =3D { ? 4 =3D> int, *int =3D> tstr }

>

> We might say this means that if a key of 4 appears, then it must have =
an int value.=C2=A0 Or, does it allow a key of 4 to appear with a text stri=
ng value while considering the optional "4 =3D> int" as being =
absent?



Yes, that is the semantics.=C2=A0 It is not always what a specifier =
might intend.



The reason is that the map opens a choice point.=C2=A0 A member with key 4 =
is starting to match the field.=C2=A0 If the value however does not=C2=A0 m=
atch (because there is no int), the matcher falls back to the choice point.=
=C2=A0 It then tries the other field, and indeed, that matches.



In the research underlying CDDL, we have discussed =E2=80=9Ccuts=E2=80=9D (=
a concept from error handling in Parse Expression Grammars (PEGs)) as the s=
olution to this.=C2=A0 If ^ represents a cut, write:



top =3D { ? 4 ^ =3D> int, *int =3D> tstr }



Once the 4 matches, there is no way back; for this member, another match is=
 no longer tried.

A nice side effect is that anything except an int after a key of 4 can give=
 a definite error message of =E2=80=9Cint expected=E2=80=9D.

The cut proposal includes : as an abbreviation for ^=3D>, so you can sim=
ply write:



top =3D { ? 4: int, *int =3D> tstr }



> Given the examples in the spec, I guess the intention is for such a th=
ing to mean the key 4, if present, has to have an int value.



Which example leads you to this conclusion?



>=C2=A0 So, there is some kind of "match the most specific key"=
; rule implied (I guess).



Actually, the PEG semantics we have borrowed here is that the *first=
* match is used.=C2=A0 But only rules are matched that indeed match!



> How that rule applies in more complex situations (where there is some =
kind of nesting) probably needs to be spelled out....=C2=A0 Given:

>

>=C2=A0 =C2=A0top =3D { 1 =3D> 1, ? ( 5 =3D> 5, 6 =3D> 6 ), *in=
t =3D> tstr }

>

> Must keys 5 & 6 be present together,



Yes.



The whole group in the parentheses is optional.



> or does the wildcard allow only one of them to appear?



(That was an early semantics we tried, and it leads down the drain.<=
br>
It is much better to have a matcher that simply and stupidly follows what=
=E2=80=99s in the grammar.)



> Or, given:

>

>=C2=A0 =C2=A0top =3D { 1 =3D> 1, ( 5 =3D> 5 // 6 =3D> 6 ), *in=
t =3D> tstr }

>

> does this mean { 1 : 1, 5 : 5, 6 : "hi" }=C2=A0 is not valid=
?



No.=C2=A0 The first field eats the 1: 1, the second field only match=
es the 5: 5, so the third field gets to eat zero or more int: tstr, of whic=
h 6: =E2=80=9Chi=E2=80=9D is a match.



> Is the 6 free to match the wildcard when the 5 has satisfied the group=
 choice?



Yes.



>

> Then there are cases where "most specific key" has no meanin=
g,



(Again, we use =E2=80=9Cfirst match=E2=80=9D.)



> such as when two key types overlap each other and neither is a single-=
value type.=C2=A0 Consider:

>

>=C2=A0 =C2=A0top =3D { * (0..10) =3D> tstr, * (5..15) =3D> int }<=
br>
>

> Does this mean a key of 5 can have either a text string or an int valu=
e?



As long as there are no cuts here, yes.



> Or, does it require that a key of 5, if present, must have a value tha=
t is both a text string and an int at the same time (i.e. it disallows 5 to=
 appear)?



That would never be the semantics =E2=80=94 the fact that there are =
two branches in a choice that can be fulfilled is not an error.



With a cut like this:



top =3D { * (0..10) ^ =3D> tstr, * (5..15) =3D> int }



this could mean that key 0..10 cut the choice and therefore need to have a =
text string value, while the rest, 11..15 can be integers, because the choi=
ce is cut after matching 0..10.



So far, we haven=E2=80=99t seen a use case that actually needed the cut, bu=
t it is still nice to have that error message.

(We also haven=E2=80=99t implemented it yet, although we will certainly do =
that over time.)



Another example where a cut helps:



message =3D orderbeer / orderwine



orderbeer =3D {

=C2=A0 type: =E2=80=9Cbeer=E2=80=9D,

=C2=A0 ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,

}



orderwine =3D {

=C2=A0 type: =E2=80=9Cwine=E2=80=9D,

=C2=A0 color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.

}



If you feed {=E2=80=9Ctype=E2=80=9D: =E2=80=9Cwine=E2=80=9D, =E2=80=9Cferme=
nt=E2=80=9D: =E2=80=9Ctop=E2=80=9D} into this, you get a rather unspecific =
error message that tells you things don=E2=80=99t match up =E2=80=94 the ma=
tcher can=E2=80=99t really know whether the =E2=80=9Ctype=E2=80=9D value of=
 =E2=80=9Cwine" or the =E2=80=9Cferment=E2=80=9D key is the =E2=80=9Cc=
ause=E2=80=9D of neither branch matching.



If you add a cut:



message =3D orderbeer / orderwine



orderbeer =3D {

=C2=A0 type: =E2=80=9Cbeer=E2=80=9D ^,

=C2=A0 ferment: =E2=80=9Cbottom=E2=80=9D / =E2=80=9Ctop=E2=80=9D,

}



orderwine =3D {

=C2=A0 type: =E2=80=9Cwine=E2=80=9D ^,

=C2=A0 color: =E2=80=9Cred=E2=80=9D / =E2=80=9Cwhite=E2=80=9D.

}



the matcher can tell you right away that the key =E2=80=9Cferment=E2=80=9D =
is not allowed in an orderwine message.



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




_______________________________________________

CBOR mailing list

CBOR@ietf.org

https://www.ietf.org/mailman/listinfo/cbor





--001a11469d86961b710554b57ea5--


From nobody Wed Jul 19 18:26:57 2017
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 CB269126E64 for ; Wed, 19 Jul 2017 18:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ERadB75YuS for ; Wed, 19 Jul 2017 18:26:54 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 06F25126C2F for ; Wed, 19 Jul 2017 18:26:54 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id o88so6219182pfk.3 for ; Wed, 19 Jul 2017 18:26:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1i4BuYMboNXn5XWxuWzj4Ur2O36MgL4eUboAeATljRs=; b=A9ltYWpm4q91z6n9ZHkZpXVBpLWsA+JOOf2D1DVBLq2Ts4qWJTjl6s5i/hvTN4+Jjc VHRLpcMGtTMmppMGzIn+n7IIOeZ9v5dYN7PSqxKvXU3tZEpCJoiEUfxOA9KmdVT/BSut myWt5r32sECw+F/oOUYa08786K2iXRMlbmRSuaoom34xsRhlKPBF4GDYJLg3x1WweF4C fLAYVhwVSYLffXUSiplnNNKMB9tsoXblcYB0cgdStWaWA0FqxkxzEoigidf/4y7fuPAn pcRqdERT4yajOu2O8HUxEaon3G3MWFuaa51aRMOs4xFoAtrWWPVqkyxihKwqNatwhKTg HtjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1i4BuYMboNXn5XWxuWzj4Ur2O36MgL4eUboAeATljRs=; b=r2Xx3OIpPI5wNgRhGZc3hdxfBbtmuFg8YSpqg3TmNgAsvPfAP3CIPmb+a2LYhjavxJ ikvcv+j1j7WK6yaU0cEzd+oktVI9pWJDR002DGa3ofvy26OO1gav9X1ZHe3MeHBwXcd0 oOaF/mPS19oSkYKgEakDiSNLXltYALZfrkq6XxxL5M6CvniASBiYlWRISbZtQDIIHxeb InHhv0gSsWn/D+ksI9yX1yZG+WJAkV9GyCNv2I8bKVXkgF367ElOEMWCdcY3mLGIfNOo N3hyeivMKtXKmFP0RNUAgNr0nsM89qFs6EejIDuVLcgE5X+BZfYpG0x/4CSsyRbuunyg WPwQ==
X-Gm-Message-State: AIVw113G207MfmEj10zGK24qEAvitFMVHe+J1jRtsP58IPNhDEx2E1zV gDC0Mj271IywxSPd
X-Received: by 10.99.113.7 with SMTP id m7mr2071773pgc.103.1500514013377; Wed, 19 Jul 2017 18:26:53 -0700 (PDT)
Received: from ?IPv6:2406:e001:3dad:1:28cc:dc4c:9703:6781? ([2406:e001:3dad:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 191sm1648021pfb.70.2017.07.19.18.26.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 18:26:52 -0700 (PDT)
To: Sean Leonard , "cbor@ietf.org" 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
Date: Thu, 20 Jul 2017 13:26:55 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 01:26:56 -0000

On 20/07/2017 03:50, Sean Leonard wrote:
> As expressed at the IETF 99 meeting, I support WG adoption of this draf=
t.

Yes

> At this time, I also support it being on the Informational track (its c=
urrent track). The track can be changed later if needed.

It's needed now. The IESG just approved at least one draft that has it as=

a normative reference. How else do you plan to precisely specify CBOR
message formats?

    Brian

>=20
> Sean
>=20
>> On Jul 5, 2017, at 2:48 AM, Francesca Palombini  wrote:
>>
>> Hi all,
>> =20
>> At the IETF98 meeting, we had in-room consensus to adopt draft-greeven=
bosch-appsawg-cbor-cddl as a starting point to work on CBOR data definiti=
on language. The authors have now updated the document and feel this is r=
eady to be a wg item.
>> =20
>> This is a confirmation call for adopting this draft as a working group=
 item. If you do not agree with the in-room consensus that we had in Chic=
ago to adopt this as a WG document, please speak up until 2017-07-19. If =
you weren=E2=80=99t in the room but do agree with adopting this document,=
 you can also tell us.
>> =20
>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 
>> =20
>> Thanks,
>> Francesca
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
>=20
>=20
>=20
>=20
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>=20


From nobody Wed Jul 19 19:00:23 2017
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 E287612EACC for ; Wed, 19 Jul 2017 19:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 35zipyLwbsFk for ; Wed, 19 Jul 2017 19:00:20 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2976F126C2F for ; Wed, 19 Jul 2017 19:00:20 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id w126so12569427wme.0 for ; Wed, 19 Jul 2017 19:00:20 -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=X/Hwm8BNghMLfW8mR1B3bJq7CtwNzCf2ydu7XTnyqI4=; b=Z8+BOpQIwl6bdEjykmzfEdqrRMySiGZ++0rXaKG+8iwq+HNqsKnW8i1YJILoVrIoa2 YmyXpG6GraLep65UutGM6Q9n+rEPTVY6/ySlrFhTtdUfQyDrHnpAzdZvu3XHDFt+6Lyh e/dU47EVX05r+c1FdfNqZf0qMtARlbMe4kU/JaBUzmyon+5K+V7bQ4pnFsNDWDUr2FJt N9AFjGfFIt5UDdb3/flsc/aUtTg/4pDFqAYrKSfyHIbkyuk+iWibijttzrZlXYOaoZXk TMhJDFCSIJKY0o81YlyEqlVkBhT7ut+ofp08ogh/gM/KiuBOnZRcnGEsOIC03v0/xD28 S9Pg==
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=X/Hwm8BNghMLfW8mR1B3bJq7CtwNzCf2ydu7XTnyqI4=; b=OqnufmsVFth5K+VpHbu5PCn8T58TeFAswEnsgcpsN5bVsu63Q8huivjRru6n3K3gm7 1lGEoNDrQV16BkRJ+z7PPVV1J4W9ZkRUO92quvUd9mnp38Ndteed9Z1zzVrXeKqm9k+M HN3IDYbI/QW7GoMIdqcHVOOhOwdd1CzwrespH6rgD0bMF0cMvoW+yLUVm3wGIIZRSzT4 HzeTMaFO47tJKzKF8QAka6D5WV0N59qjd8qEc4lHtYV2E1Rom9qzJQLWZsqQpM7klOaG VKKbW3n+Eq0Bn1RszXQtXIXnwPZ9idwrmwKQKn86Hg8ki38ZXWuXoI+epQuSIwiIKYU4 odzg==
X-Gm-Message-State: AIVw1114jg7/c5MignQJSeP1knrgPJgmcoDHBemGJB8oB1TJiXKq18WX UPB6XSiGEqgVqEsuZhhNmUxPxcqk49ZTviIltQ==
X-Received: by 10.28.71.133 with SMTP id m5mr1198513wmi.97.1500516018236; Wed, 19 Jul 2017 19:00:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.216.144 with HTTP; Wed, 19 Jul 2017 18:59:57 -0700 (PDT)
From: Jeffrey Yasskin 
Date: Thu, 20 Jul 2017 03:59:57 +0200
Message-ID: 
To: cbor@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c074e7e3fac1a0554b61c71"
Archived-At: 
Subject: [Cbor] Is draft-bormann-cbor-time-tag unnecessary?
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, 20 Jul 2017 02:00:22 -0000

--94eb2c074e7e3fac1a0554b61c71
Content-Type: text/plain; charset="UTF-8"

Hi all,

I think the new time tag is unnecessary. It's more complex than extending
tag 1 to accept BigDecimal and BigFloats, and it costs more bytes (20 vs 15
for a current use of picosecond resolution, if I counted right).

One objection could be that RFC7049 already specifies that only types 0, 1,
and 7 will appear inside tag 1, and so generic parsers could be confused if
people put bignums there. Two responses:
1) I believe people are mostly designing individual protocols with CBOR,
and not relying on deployed generic parsers being able to handle new
protocols. When a particular protocol specifies use of the time tag, it
needs to specify which numeric formats are ok inside it (e.g. "no floats"
is quite reasonable), and that protocol's parsers can be implemented to
match.
2) If we can't change tag 1, I think it's still simpler to add a POSIX time
tag that allows more numeric formats, rather than adding the proposed
map-based format.

I think a new tag would be justified to encode a different time standard
like TAI or real UTC, whenever folks need those.

Jeffrey

--94eb2c074e7e3fac1a0554b61c71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,

I think the new time tag is unn=
ecessary. It's more complex than extending tag 1 to accept BigDecimal a=
nd BigFloats, and it costs more bytes (20 vs 15 for a current use of picose=
cond resolution, if I counted right).

One objectio=
n could be that RFC7049 already specifies that only types 0, 1, and 7 will =
appear inside tag 1, and so generic parsers could be confused if people put=
 bignums there. Two responses:
1) I believe people are mostly des=
igning individual protocols with CBOR, and not relying on deployed generic =
parsers being able to handle new protocols. When a particular protocol spec=
ifies use of the time tag, it needs to specify which numeric formats are ok=
 inside it (e.g. "no floats" is quite reasonable), and that proto=
col's parsers can be implemented to match.
2) If we can't=
 change tag 1, I think it's still simpler to add a POSIX time tag that =
allows more numeric formats, rather than adding the proposed map-based form=
at.

I think a new tag would be justified to encode=
 a different time standard like TAI or real UTC, whenever folks need those.=


Jeffrey


--94eb2c074e7e3fac1a0554b61c71--


From nobody Wed Jul 19 22:17:20 2017
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 875C2131803 for ; Wed, 19 Jul 2017 22:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 CFCp7CfGzvNZ for ; Wed, 19 Jul 2017 22:17:17 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 0DEF3131748 for ; Wed, 19 Jul 2017 22:17:17 -0700 (PDT)
Received: from [192.168.122.105] (unknown [174.65.80.226]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4655D22E1F3; Thu, 20 Jul 2017 01:17:04 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Leonard 
In-Reply-To: 
Date: Wed, 19 Jul 2017 22:17:02 -0700
Cc: cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <96FC742A-AAF0-4CA2-8E63-243316E894ED@seantek.com>
References: 
To: Jeffrey Yasskin 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Is draft-bormann-cbor-time-tag unnecessary?
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, 20 Jul 2017 05:17:18 -0000

> On Jul 19, 2017, at 6:59 PM, Jeffrey Yasskin  =
wrote:
>=20
> Hi all,
>=20
> I think the new time tag is unnecessary. It's more complex than =
extending tag 1 to accept BigDecimal and BigFloats, and it costs more =
bytes (20 vs 15 for a current use of picosecond resolution, if I counted =
right).
>=20
> One objection could be that RFC7049 already specifies that only types =
0, 1, and 7 will appear inside tag 1, and so generic parsers could be =
confused if people put bignums there. Two responses:
> 1) I believe people are mostly designing individual protocols with =
CBOR, and not relying on deployed generic parsers being able to handle =
new protocols. When a particular protocol specifies use of the time tag, =
it needs to specify which numeric formats are ok inside it (e.g. "no =
floats" is quite reasonable), and that protocol's parsers can be =
implemented to match.
> 2) If we can't change tag 1, I think it's still simpler to add a POSIX =
time tag that allows more numeric formats, rather than adding the =
proposed map-based format.

I have always believed that it is, or should be, acceptable to extend =
the tags to accept more major types.

This is also the same issue with tag 36 for =E2=80=9CMIME Message=E2=80=9D=
, as discussed in the WG document draft-bormann-cbor-tags-oid-06.

Ultimately it is a =E2=80=9Cstyle issue=E2=80=9D that nobody has raised =
serious objections against (to expanding a tag); however, the matter has =
not been thoroughly discussed and =E2=80=9Cconsensus-ed=E2=80=9D upon, =
either.

(In this message at this time, I do not express an opinion about whether =
a new time tag is necessary.)

Regards,

Sean

>=20
> I think a new tag would be justified to encode a different time =
standard like TAI or real UTC, whenever folks need those.



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


From nobody Thu Jul 20 04:26:04 2017
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 23FA2131C12 for ; Thu, 20 Jul 2017 04:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoOVb2ohozte for ; Thu, 20 Jul 2017 04:25:58 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 4EA42131C14 for ; Thu, 20 Jul 2017 04:25:51 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id w126so21686158wme.0 for ; Thu, 20 Jul 2017 04:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xelRXTIZWFjcjcA+Nf/cTk4BGgpmet56hJc5hyDwZvo=; b=O85Xx7XDAH1sq5DU/vmsgESlD5RNMqML27PwoyExQHyh08ar5a7dpUp2w9iHGNbqYu ewpnryESLwjZclEOF5hzeEACimKs0sgmfS1cr60OmC6iB9NqokqHQDjARoRZGvfqq+du vgKcFr+TkhyVI41Mm4lq6CBxoPyyx6XK5WsBLi7t4iJe39Jm54GOZMVJulXNfmJyEnLS e35VT6NyQkm54gaUb5F6DqfliL70i1qoe/2tdpdb7OUOmOYpY6PKpfBaazmJApX9k88e nUt84Xym1agiMUzMZFiMqyrADuQr6pREehDGF7s7Ip3Ht/MiCVrFQYS7kb0Thuf9sEkO 3xpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xelRXTIZWFjcjcA+Nf/cTk4BGgpmet56hJc5hyDwZvo=; b=pg0mnpySRr0I0koerLDhQBg/Zg4aLXSpiqTU2AOTjDbKiCnrJD5/QTcYl1LMr5t30q CTH7lOjNQgL4PUweFNKOU8DYWqSk62pCV8VaSn0i1h/Kv0359tV9HxIxoLlV27ODR9f5 mNwahR+Rk+oFMSoBsfdSCTRIIQkjvY6NnBLKan6uP0//peG4iU9i7xqBhnV4fMk8Kw1K CclhATb0tsfPxFpbbe2kTSCf62C/KGqxqfkYS5W96Lm1HuC9Lsx2bDpMJoLdF5SMEVCZ 57vgEm6U0yvHKfaDwdXk1Cf/LlbN+xvt94GV8MwNaK2Xy7Sag7epj0LDQK3Jt2Fn/Iw6 3+tA==
X-Gm-Message-State: AIVw1126LjVBw9MKqJt+/AZ0s3rp920FjshwVrGdEdhtyrcPOWo6wMcp Dt2DlR6QaH8FgmRqMSEP1w==
X-Received: by 10.28.234.18 with SMTP id i18mr101343wmh.89.1500549949359; Thu, 20 Jul 2017 04:25:49 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:1006:f2c2:920c:b511? ([2001:67c:370:128:1006:f2c2:920c:b511]) by smtp.gmail.com with ESMTPSA id k45sm6297899wrk.45.2017.07.20.04.25.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 04:25:48 -0700 (PDT)
To: cbor@ietf.org
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
From: "Matthew A. Miller" 
Message-ID: 
Date: Thu, 20 Jul 2017 13:25:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0
MIME-Version: 1.0
In-Reply-To: <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6xhi6ssfvDn5Vf399osoj7UJL8ufx7jJE"
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 11:26:00 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6xhi6ssfvDn5Vf399osoj7UJL8ufx7jJE
Content-Type: multipart/mixed; boundary="2RAAHoV0KWCqU8Ik7q1cDcxXivLFdB1I2";
 protected-headers="v1"
From: "Matthew A. Miller" 
To: cbor@ietf.org
Message-ID: 
Subject: =?UTF-8?Q?Re:_[Cbor]_=f0=9f=94=94_Confirmation_call_for_Working_Gro?=
 =?UTF-8?Q?up_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
References: 
 <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com>
 <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
In-Reply-To: <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>

--2RAAHoV0KWCqU8Ik7q1cDcxXivLFdB1I2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable


On 17/07/20 03:26, Brian E Carpenter wrote:
> On 20/07/2017 03:50, Sean Leonard wrote:
>> As expressed at the IETF 99 meeting, I support WG adoption of this dra=
ft.
>=20
> Yes
>=20
>> At this time, I also support it being on the Informational track (its =
current track). The track can be changed later if needed.
>=20
> It's needed now. The IESG just approved at least one draft that has it =
as
> a normative reference. How else do you plan to precisely specify CBOR
> message formats?
>=20

I agree, and the practical work to convert from informational to
standards track is a single line change in the source.  I suggest the
chairs tell the authors/editors make that change to the
"draft-ietf-cbor-cddl-00" they submit.


- m&m

Matthew A. Miller
< http://goo.gl/LM55L >


--2RAAHoV0KWCqU8Ik7q1cDcxXivLFdB1I2--

--6xhi6ssfvDn5Vf399osoj7UJL8ufx7jJE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJZcJM9AAoJEOz0ck4QngW7fkwH/08lKnC19YEqP4uhBo/BNqLQ
LYaR+eaKoG+S6XNpCS//0aACE5P7IfFAyMGEHPiASgW6Z0xpHCJbaaVE0Ew9VPGC
cmy7DZa+XeDK5u2pr/cwtIZEokLPQmerESTQygELTL/1c3GnQLdrXZ5K70Pg2ZQj
IjOK8MgBMHeqvUSdzjiC91/Q/m9UkJnpQnQD9X71HoIIl5H+jlu7oDAm0xw5saMU
QwASNKwdftX6AJDR51JhYWWLlkPjqZ9mPv4VLV9Z0rQVsHAgtM6wB4vNsl61wHjX
U/RV1E3w0nPR/73dTrXcwMF0UqOyfq5k8C0EF7o5Fv0KnvhH/cFC0WVLbRK/N/E=
=tcv0
-----END PGP SIGNATURE-----

--6xhi6ssfvDn5Vf399osoj7UJL8ufx7jJE--


From nobody Thu Jul 20 07:04:08 2017
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 6181C1288B8 for ; Thu, 20 Jul 2017 07:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 JbEN9j-4RRBf for ; Thu, 20 Jul 2017 07:04:03 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 C6BD512704A for ; Thu, 20 Jul 2017 07:04:02 -0700 (PDT)
Received: from [192.168.1.216] (unknown [70.166.5.157]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BF0F22E1F3; Thu, 20 Jul 2017 10:03:49 -0400 (EDT)
From: Sean Leonard 
Message-Id: <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F37F9E59-CE5C-4790-935F-65F89EFD1743"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 07:03:48 -0700
In-Reply-To: <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
Cc: "cbor@ietf.org" 
To: Brian E Carpenter 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 14:04:07 -0000

--Apple-Mail=_F37F9E59-CE5C-4790-935F-65F89EFD1743
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 19, 2017, at 6:26 PM, Brian E Carpenter =
 wrote:
>=20
> On 20/07/2017 03:50, Sean Leonard wrote:
>> As expressed at the IETF 99 meeting, I support WG adoption of this =
draft.
>=20
> Yes
>=20
>> At this time, I also support it being on the Informational track (its =
current track). The track can be changed later if needed.
>=20
> It's needed now. The IESG just approved at least one draft that has it =
as
> a normative reference. How else do you plan to precisely specify CBOR
> message formats?

=E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice to have. It =
is better to have a stable reference. But =E2=80=9Cstable references=E2=80=
=9D are also harder to make technical changes to as more people rely on =
it and come up with arguments for how things can never change because =
they already wrote/deployed stuff.

It=E2=80=99s not just the documents that reference this one: it=E2=80=99s =
also the documents that CDDL references. By way of example, CDDL depends =
on regular expressions, and specifically calls out PCRE. PCRE is great =
but is in no way a Standard; it=E2=80=99s a single implementation. There =
is a lot of variation in regular expression engines, and the most useful =
ones (thinking about PCRE, Python, Perl, and .NET) are not SDO =
standards. There are some features in this draft that have not even been =
implemented yet.

There are other examples of documents (most notably, JSON) that started =
off as Informational and got promoted to Standards Track later.

CDDL is descriptive (data description language), rather than =
prescriptive. Sections 4.1 and 4.2. It currently falls far more into the =
Markdown-esque side of things (Postel=E2=80=99s Law), rather than the =
XML schema-esque side of things (all errors are fatal). =E2=80=9CThe =
matter in how far the data description must be enforced by an =
application is left to the designers and implementers of that =
application [=E2=80=A6].=E2=80=9D This is a Good Thing. One glaring =
point is that a CDDL grammar does not exclusively define all =
possibilities. You can define a struct with members {foo: tstr, bar: =
tstr, baz: uint} in CDDL. What if the data contains {foo: =E2=80=9Ca=E2=80=
=9D, bar: =E2=80=9Cb=E2=80=9D, baz: 6, fred: =E2=80=98ffdeff=E2=80=99} ? =
What if you have {foo: -1}? CDDL doesn=E2=80=99t say whether those are =
fatal errors. That=E2=80=99s okay, Postel=E2=80=99s law and all. It =
means that a CDDL processor can be implemented in far less code for =
resource-constrained devices. But there may be very serious security =
considerations.

For now, you can precisely define your CBOR message format using prose. =
Or you can use some combination of CDDL and prose. Just reference CDDL =
informatively.

As has been pointed out, it=E2=80=99s a one-line change, and it can be =
done later.

Best regards,

Sean

>=20
>    Brian
>=20
>>=20
>> Sean
>>=20
>>> On Jul 5, 2017, at 2:48 AM, Francesca Palombini =
 wrote:
>>>=20
>>> Hi all,
>>>=20
>>> At the IETF98 meeting, we had in-room consensus to adopt =
draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR =
data definition language. The authors have now updated the document and =
feel this is ready to be a wg item.
>>>=20
>>> This is a confirmation call for adopting this draft as a working =
group item. If you do not agree with the in-room consensus that we had =
in Chicago to adopt this as a WG document, please speak up until =
2017-07-19. If you weren=E2=80=99t in the room but do agree with =
adopting this document, you can also tell us.
>>>=20
>>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 =

>>>=20
>>> Thanks,
>>> Francesca
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>>=20
>>=20
>>=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


--Apple-Mail=_F37F9E59-CE5C-4790-935F-65F89EFD1743
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jul 19, 2017, at 6:26 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On =
20/07/2017 03:50, Sean Leonard wrote:
As expressed at the IETF 99 meeting, I support =
WG adoption of this draft.

Yes

At this time, I also support it being on the Informational =
track (its current track). The track can be changed later if needed.

It's needed now. The IESG just =
approved at least one draft that has it as
a normative =
reference. How else do you plan to precisely specify CBOR
message formats?

=E2=80=9CNeed=E2=80=9D is a very subjective word. =
It is nice to have. It is better to have a stable reference. But =
=E2=80=9Cstable references=E2=80=9D are also harder to make technical =
changes to as more people rely on it and come up with arguments for how =
things can never change because they already wrote/deployed =
stuff.

It=E2=80=99s not just the =
documents that reference this one: it=E2=80=99s also the documents that =
CDDL references. By way of example, CDDL depends on regular expressions, =
and specifically calls out PCRE. PCRE is great but is in no way a =
Standard; it=E2=80=99s a single implementation. There is a lot of =
variation in regular expression engines, and the most useful ones =
(thinking about PCRE, Python, Perl, and .NET) are not SDO standards. =
There are some features in this draft that have not even been =
implemented yet.

There are other =
examples of documents (most notably, JSON) that started off as =
Informational and got promoted to Standards Track later.

CDDL is descriptive (data =
description language), rather than prescriptive. =
Sections 4.1 and 4.2. It currently falls far more into the =
Markdown-esque side of things (Postel=E2=80=99s Law), rather than the =
XML schema-esque side of things (all errors are fatal). =E2=80=9CThe matter in how =
far the data description must be enforced by an application is =
left to the designers and implementers of that application [=E2=80=A6].=E2=80=9D This =
is a Good Thing. One glaring point is that a CDDL grammar does not =
exclusively define all possibilities. You can define a struct with =
members {foo: tstr, bar: tstr, baz: uint} in CDDL. What if the data =
contains {foo: =E2=80=9Ca=E2=80=9D, bar: =E2=80=9Cb=E2=80=9D, baz: 6, =
fred: =E2=80=98ffdeff=E2=80=99} ? What if you have {foo: -1}? CDDL =
doesn=E2=80=99t say whether those are fatal errors. That=E2=80=99s okay, =
Postel=E2=80=99s law and all. It means that a CDDL processor can be =
implemented in far less code for resource-constrained devices. But there =
may be very serious security considerations.

For now, you can precisely define your CBOR =
message format using prose. Or you can use some combination of CDDL and =
prose. Just reference CDDL informatively.

As has been pointed out, it=E2=80=99s a one-line =
change, and it can be done later.

Best=
 regards,

Sean


    Brian


Sean

On Jul 5, =
2017, at 2:48 AM, Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi all,

At the =
IETF98 meeting, we had in-room consensus to adopt =
draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR =
data definition language. The authors have now updated the document and =
feel this is ready to be a wg item.

This is =
a confirmation call for adopting this draft as a working group item. If =
you do not agree with the in-room consensus that we had in Chicago to =
adopt this as a WG document, please speak up until 2017-07-19. If you =
weren=E2=80=99t in the room but do agree with adopting this document, =
you can also tell us.

https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cdd=
l-11 <https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cdd=
l-11>

Thanks,
Francesca
_______________________________________________
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

=

--Apple-Mail=_F37F9E59-CE5C-4790-935F-65F89EFD1743--


From nobody Thu Jul 20 07:17:05 2017
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 A6E65129ADD for ; Thu, 20 Jul 2017 07:16:59 -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 A7ADAdhiqmqL for ; Thu, 20 Jul 2017 07:16:58 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF6013146C for ; Thu, 20 Jul 2017 07:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6KEGqTT009129; Thu, 20 Jul 2017 16:16:52 +0200 (CEST)
Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (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 3xCwv860KLz3Z9y; Thu, 20 Jul 2017 16:16:52 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
Date: Thu, 20 Jul 2017 16:16:52 +0200
Cc: Brian E Carpenter , "cbor@ietf.org" 
X-Mao-Original-Outgoing-Id: 522253011.963885-5e589b01f92f1e4f788c9599e0f95777
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 14:17:03 -0000

On Jul 20, 2017, at 16:03, Sean Leonard  wrote:
>=20
> For now, you can precisely define your CBOR message format using =
prose.

The point of creating this WG and chartering it with completing the CDDL =
spec was that that frustrating exercise shall no longer be needed, just =
as ABNF has solved the same problem for textual protocols.

After reading your message, I still have no idea why you don=E2=80=99t =
want us to do this.

(Re the one substantive comment about PCRE: That family of languages is =
definitely more well-defined than the family known as "English =
language=E2=80=9D.  If you think we need to point a spec, we can always =
use ECMA 262; I don=E2=80=99t think we need all of PCRE.  We could also =
remove the .regexp control, but I think it is too useful to do that.  We =
maybe should add a warning that specifiers should avoid the weird ends =
of PCRE.  None of this is relevant to the question at hand, WG =
adoption.)

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


From nobody Thu Jul 20 07:22:45 2017
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 05AD112704A for ; Thu, 20 Jul 2017 07:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 F_UEYMUiHpdO for ; Thu, 20 Jul 2017 07:22:34 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 E730B13146E for ; Thu, 20 Jul 2017 07:22:21 -0700 (PDT)
Received: from [192.168.1.216] (unknown [70.166.5.157]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E3D4222E271; Thu, 20 Jul 2017 10:22:20 -0400 (EDT)
From: Sean Leonard 
Message-Id: <774331C9-367B-45D6-B4DC-ED36D2589D17@seantek.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A332714B-3FE7-4BC0-8880-BC631DCDF791"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 20 Jul 2017 07:22:19 -0700
In-Reply-To: 
Cc: Brian E Carpenter , "cbor@ietf.org" 
To: Carsten Bormann 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 14:22:44 -0000

--Apple-Mail=_A332714B-3FE7-4BC0-8880-BC631DCDF791
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 20, 2017, at 7:16 AM, Carsten Bormann  wrote:
>=20
> On Jul 20, 2017, at 16:03, Sean Leonard  wrote:
>>=20
>> For now, you can precisely define your CBOR message format using =
prose.
>=20
> The point of creating this WG and chartering it with completing the =
CDDL spec was that that frustrating exercise shall no longer be needed, =
just as ABNF has solved the same problem for textual protocols.

That was not my full quote. I wrote: =E2=80=9CFor now, you can precisely =
define your CBOR message format using prose. Or you can use some =
combination of CDDL and prose. Just reference CDDL informatively.=E2=80=9D=
 Since that is what the current CDDL draft itself says: =E2=80=9CThe =
matter in how far the data description must be enforced by an =
application is left to the designers and implementers of that =
application [=E2=80=A6].=E2=80=9D=20

On the original point of this thread, I continue to support WG adoption.

Regards,

Sean


--Apple-Mail=_A332714B-3FE7-4BC0-8880-BC631DCDF791
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jul 20, 2017, at 7:16 AM, Carsten Bormann <cabo@tzi.org> =
wrote:

On Jul 20, 2017, at 16:03, Sean Leonard <dev+ietf@seantek.com> wrote:

For now, you can precisely =
define your CBOR message format using prose.

The point of creating this WG and =
chartering it with completing the CDDL spec was that that frustrating =
exercise shall no longer be needed, just as ABNF has solved the same =
problem for textual protocols.

That =
was not my full quote. I wrote: =E2=80=9CFor now, you can precisely define your =
CBOR message format using prose. Or you can use some combination of CDDL =
and prose. Just reference CDDL informatively.=E2=80=9D Since that =
is what the current CDDL draft itself says: =E2=80=9CThe matter in how far the data description must =
be enforced by an application is left =
to the designers and implementers of that application =
[=E2=80=A6].=E2=80=9D 

On =
the original point of this thread, I continue to support WG =
adoption.

Regards,

Sean

=

--Apple-Mail=_A332714B-3FE7-4BC0-8880-BC631DCDF791--


From nobody Thu Jul 20 07:26:09 2017
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 E323413146E for ; Thu, 20 Jul 2017 07:26:06 -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 foknlHSSkT2N for ; Thu, 20 Jul 2017 07:26:05 -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 786471288B8 for ; Thu, 20 Jul 2017 07:26:05 -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 v6KEPunE016918; Thu, 20 Jul 2017 16:25:56 +0200 (CEST)
Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (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 3xCx5c38NVz3ZB6; Thu, 20 Jul 2017 16:25:56 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: <774331C9-367B-45D6-B4DC-ED36D2589D17@seantek.com>
Date: Thu, 20 Jul 2017 16:25:55 +0200
Cc: Brian E Carpenter , "cbor@ietf.org" 
X-Mao-Original-Outgoing-Id: 522253555.610408-16eaa010803bceb4d07110e2bc43b13c
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>  <774331C9-367B-45D6-B4DC-ED36D2589D17@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 20 Jul 2017 14:26:07 -0000

On Jul 20, 2017, at 16:22, Sean Leonard  wrote:
>=20
> That was not my full quote. I wrote: =E2=80=9CFor now, you can =
precisely define your CBOR message format using prose. Or you can use =
some combination of CDDL and prose. Just reference CDDL =
informatively.=E2=80=9D Since that is what the current CDDL draft itself =
says: =E2=80=9CThe matter in how far the data description must be =
enforced by an application is left to the designers and implementers of =
that application [=E2=80=A6].=E2=80=9D=20

Which variation includes the use of CDDL as the exact specification of =
the data exchanged.
For this to be possible, the CDDL language spec must be standards track =
or downref-enabled informational.
The latter is a bit circuitous =E2=80=94 if the point is being =
normative, we might as well make it standards track.

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


From nobody Thu Jul 20 21:25:06 2017
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 47C26129B77 for ; Thu, 20 Jul 2017 21:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQmf7Ijan_SB for ; Thu, 20 Jul 2017 21:25:04 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 18B0E12441E for ; Thu, 20 Jul 2017 21:25:04 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id r76so2564269pfj.2 for ; Thu, 20 Jul 2017 21:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Sv9YvHmddi9o6JpDsqXf2nA69iOyw0UgQnRgu6r7I4k=; b=FrhXaWA18mASmyyMkHNyWqPcc1uEACFmjrQUBtCBRmMWabvePdnPYugL5W7dPnKFNl GpHEygDffqWcj2xg0mk5tdXYAvf8krDYwZ0Ck9dy3VBA3sNEuJafHBaoRYL6pNPDiv2Q F70eNMa0uaJC3SXyl7iJTJLksgcM04gj22U7FMgq8cn/7n6XFqtPe8XoUrcubvTu1d4Q bjRxO2pGKmOjLfVEoiUBKaa0VgnZz7tCsWo5DaYyCWmjKaODBNNQ3x0IgqPP0NXIGaXS 8wDyOCl/SDiOjQM8LNfOZIY/An3vcXTJKIWO36tPI7SO5uQRcsuc+twcSRhCtLF39ROy SzpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Sv9YvHmddi9o6JpDsqXf2nA69iOyw0UgQnRgu6r7I4k=; b=Bk8EoBdeYUVTVwDHn1mCo2L08A0sfGsj8FwDmkA8eDUhX0tfIustQQGXrl0LvOoBhc RJQEdxmnveUcsWEptzgO0FwkLJJGjWl73UUm5Wa+7wicKeYdPlLFMIokden/JamAUsAg XP2VkacKjGPMYHKSCxX2r5FSA9OCGfR1KnANlkfFp/nDeg/zAdZmY5mPU440pwehOSrR y7c7VimegDNzPI40BlkCdinpfz43O6SMgR1pVZU4/46LpIULFOOKank+uaJ+QJq7mY8h sIvWRrxwOaRxhPU34llHeqpGU/bu3HqL+zFIHh1oGGI+xGBrhwAKNSrbwpzbovWZA7CB stDQ==
X-Gm-Message-State: AIVw113yP603hsiAqZoQvhq867bGUW7u0C09Ym/bxPySeBT50G1GPrVU 4fg33va68YisMgbt
X-Received: by 10.99.168.76 with SMTP id i12mr6066154pgp.391.1500611103097; Thu, 20 Jul 2017 21:25:03 -0700 (PDT)
Received: from [192.168.178.21] ([118.148.121.166]) by smtp.gmail.com with ESMTPSA id y11sm6885502pfd.144.2017.07.20.21.25.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 21:25:02 -0700 (PDT)
To: Sean Leonard 
Cc: "cbor@ietf.org" 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 21 Jul 2017 16:25:07 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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: Fri, 21 Jul 2017 04:25:05 -0000

On 21/07/2017 02:03, Sean Leonard wrote:
>=20
>> On Jul 19, 2017, at 6:26 PM, Brian E Carpenter  wrote:
>>
>> On 20/07/2017 03:50, Sean Leonard wrote:
>>> As expressed at the IETF 99 meeting, I support WG adoption of this dr=
aft.
>>
>> Yes
>>
>>> At this time, I also support it being on the Informational track (its=
 current track). The track can be changed later if needed.
>>
>> It's needed now. The IESG just approved at least one draft that has it=
 as
>> a normative reference. How else do you plan to precisely specify CBOR
>> message formats?
>=20
> =E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice to have.=20

No, I said "need" and I meant "need". A normative reference is a need.

    Brian


From nobody Fri Jul 21 03:05:39 2017
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 6B2B4127ABE for ; Fri, 21 Jul 2017 03:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XtCAZNj43eQa for ; Fri, 21 Jul 2017 03:05:37 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DD5127869 for ; Fri, 21 Jul 2017 03:05:36 -0700 (PDT)
Received: from dooku.sandelman.ca (dhcp-9cfb.meeting.ietf.org [31.133.156.251]) by relay.sandelman.ca (Postfix) with ESMTPS id F17D21F8F6; Fri, 21 Jul 2017 10:05:34 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 92C931638; Fri, 21 Jul 2017 12:05:22 +0200 (CEST)
From: Michael Richardson 
To: "cbor\@ietf.org" 
CC: Sean Leonard , Brian E Carpenter 
In-reply-to: <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com>
Comments: In-reply-to Sean Leonard  message dated "Thu, 20 Jul 2017 07:03:48 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 21 Jul 2017 12:05:22 +0200
Message-ID: <2531.1500631522@dooku.sandelman.ca>
Archived-At: 
Subject: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents?
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: Fri, 21 Jul 2017 10:05:38 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Between starting this email, and pushing send, I went to find RFC-editor.
She happened to be sitting with the AD responsible for GRASP.  Both said
that the downref would be permitted only when the use of CDDL was very
loose.  Otherwise, it would be a problem.

I feel strongly that we need it to be standards track.

Sean Leonard  wrote:
    >     It's needed now. The IESG just approved at least one draft that h=
as
    > it as a normative reference. How else do you plan to precisely specify
    > CBOR message formats?


    > =E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice to have.=
 It is better to
    > have a stable reference. But =E2=80=9Cstable references=E2=80=9D are =
also harder to
    > make technical changes to as more people rely on it and come up with
    > arguments for how things can never change because they already
    > wrote/deployed stuff.

This doesn't matter for CDDL the way it does for, i.e. IPv6.

A specification is going to reference a *SPECIFIC* version of CDDL, and
it just fine if we make changes in a new version.  We do need an annotation
for the compilers/checkers/, etc. what version they should process, but
for the purposes of referencing CDDL, we do not have to worry if
it changes afterwards.

    > It=E2=80=99s not just the documents that reference this one: it=E2=80=
=99s also the
    > documents that CDDL references. By way of example, CDDL depends on
    > regular expressions, and specifically calls out PCRE. PCRE is great b=
ut
    > is in no way a Standard; it=E2=80=99s a single implementation. There =
is a lot
    > of variation in regular expression engines, and the most useful ones
    > (thinking about PCRE, Python, Perl, and .NET) are not SDO
    > standards. There are some features in this draft that have not even
    > been implemented yet.

The lack of a specification for PCRE sounds like a more serious problem
regardless of the status we intend for the document.

    > For now, you can precisely define your CBOR message format using
    > prose. Or you can use some combination of CDDL and prose. Just
    > reference CDDL informatively.

That just isn't useful.
If you tell us to use prose, then our next step will be to write a
specification so that we don't have to be so imprecise.

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        | network architect=
  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [






=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJZcdHiAAoJEJVM4Vb9/EKQXKYH+gJBib43EQ2MmjVs2/OZaI6I
KCoKHxdw/pEaiLPVbu9MS6zTGz/gElucHi3dWezxQO5PwdJvG3870K5Hhe/fWlMa
7t9okpEq/YoSzU05yRWTRMNNakF+kLPY7g7KWedEFdQNQqsSAhjBgCjkQXkxXpyb
Yd6wkjk66dbyiRR8sBgwmQqZUrmWu4So1gqCaVyl2JThfEwHRL7WGN8aridzejGD
v3MucU+Gbu2qZYZbnCQ3r04r+DWjXxDb1Js0KPlM6A77KQlFAHT/fHAH9r+joLbT
vVOsdFFv6IqtFqYFHx5uC/uwLDYZK0vKtPIGKmnZdVkFmz8jZDDeO5QZEV0ff3g=
=HXLr
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Jul 21 03:38:23 2017
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 A314C12EB2B for ; Fri, 21 Jul 2017 03:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 QNiL-ICpYkDA for ; Fri, 21 Jul 2017 03:38:21 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 CBA43127337 for ; Fri, 21 Jul 2017 03:38:20 -0700 (PDT)
Received: from [192.168.1.39] (unknown [184.191.181.73]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9D58B509B8; Fri, 21 Jul 2017 06:38:19 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Leonard 
In-Reply-To: <2531.1500631522@dooku.sandelman.ca>
Date: Fri, 21 Jul 2017 03:38:18 -0700
Cc: "cbor@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> <2531.1500631522@dooku.sandelman.ca>
To: Michael Richardson 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents?
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: Fri, 21 Jul 2017 10:38:23 -0000

Michael, the underlying concern/fear that I have about this CDDL work, =
remains that despite it being nascent, people will immediately complain =
that such-and-such features of CDDL can never change because they =
already wrote stuff.=20

Better to get it right, and that means, at this stage, that all features =
of the language are up for grabs.

(Even in writing this, I=E2=80=99m fully aware that the basic =
structures, namely vector, record, table, and struct, are very unlikely =
to change. But some of the unlikeliness will undoubtedly be due to =
people saying they already wrote stuff. Compare with RFC 8152, which =
copes all right under the circumstances given the timing of its =
publication.)

Back at the March meeting, I recall that the chairs asked the WG =
participants about the possibility of publishing a lightweight CDDL RFC =
to take pressure off. I don=E2=80=99t think I saw follow-up on that on =
the list though.

(By the way, are there IETF 98 meeting minutes? I can=E2=80=99t find =
minutes from IETF 98 based on quick Google and mailing list searches.)

> On Jul 21, 2017, at 3:05 AM, Michael Richardson =
 wrote:
>=20
>=20
> Between starting this email, and pushing send, I went to find =
RFC-editor.
> She happened to be sitting with the AD responsible for GRASP.  Both =
said
> that the downref would be permitted only when the use of CDDL was very
> loose.  Otherwise, it would be a problem.
>=20
> I feel strongly that we need it to be standards track.
>=20
> Sean Leonard  wrote:
>>    It's needed now. The IESG just approved at least one draft that =
has
>> it as a normative reference. How else do you plan to precisely =
specify
>> CBOR message formats?
>=20
>=20
>> =E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice to have. =
It is better to
>> have a stable reference. But =E2=80=9Cstable references=E2=80=9D are =
also harder to
>> make technical changes to as more people rely on it and come up with
>> arguments for how things can never change because they already
>> wrote/deployed stuff.
>=20
> This doesn't matter for CDDL the way it does for, i.e. IPv6.
>=20
> A specification is going to reference a *SPECIFIC* version of CDDL, =
and
> it just fine if we make changes in a new version.  We do need an =
annotation
> for the compilers/checkers/, etc. what version they should process, =
but
> for the purposes of referencing CDDL, we do not have to worry if
> it changes afterwards.

I really don=E2=80=99t want us to have to start versioning CDDL before =
the WG even takes it up. I would like to point out that ABNF is not =
=E2=80=9Cversioned=E2=80=9D (aside from successive x234 RFCs being =
published), and people are getting along just fine. That is because the =
primary way that ABNF is used is =E2=80=9Cas a guide to a human user=E2=80=
=9D, even though it can be run through compilers/validators. And CDDL is =
still on that ABNF side of the spectrum, rather than the (unreadable) =
XML Schema side of the spectrum.

If by =E2=80=9C*SPECIFIC* version of CDDL=E2=80=9D you are referring to =
the technique in RFC 8152, then that=E2=80=99s fine.

>=20
>> It=E2=80=99s not just the documents that reference this one: it=E2=80=99=
s also the
>> documents that CDDL references. By way of example, CDDL depends on
>> regular expressions, and specifically calls out PCRE. PCRE is great =
but
>> is in no way a Standard; it=E2=80=99s a single implementation. There =
is a lot
>> of variation in regular expression engines, and the most useful ones
>> (thinking about PCRE, Python, Perl, and .NET) are not SDO
>> standards. There are some features in this draft that have not even
>> been implemented yet.
>=20
> The lack of a specification for PCRE sounds like a more serious =
problem
> regardless of the status we intend for the document.

It is. And it is not.

PCRE is mentioned in RFC 7049, along with JavaScript syntax. Guess the =
lack of reference escaped review.

At the level of informally saying hey, use regular expressions here, =
it=E2=80=99s cool. But at the level of demanding implementations conform =
to supporting PCRE specifically, and that standard documents written =
with regular expressions import PCRE, it=E2=80=99s not cool (unless the =
WG considers it and says okay).

Anyway, I hope that we can conclude the WG adoption call and then =
proceed to the work, which will make everything go more speedily. :-)

Regards,

Sean


From nobody Fri Jul 21 05:29:09 2017
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 1487712EAF0 for ; Fri, 21 Jul 2017 05:29:07 -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 857Ncum_dBWQ for ; Fri, 21 Jul 2017 05:29:05 -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 E8CD4127735 for ; Fri, 21 Jul 2017 05:29:04 -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 v6LCT1FI022210; Fri, 21 Jul 2017 14:29:01 +0200 (CEST)
Received: from client-0032.vpn.uni-bremen.de (client-0032.vpn.uni-bremen.de [134.102.107.32]) (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 3xDVSF2dkCz3ZRV; Fri, 21 Jul 2017 14:29:01 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Fri, 21 Jul 2017 14:29:00 +0200
Cc: Michael Richardson , "cbor@ietf.org" 
X-Mao-Original-Outgoing-Id: 522332940.669308-82fd3cfa1143b0437cfe5f60d4ff14e0
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> <2531.1500631522@dooku.sandelman.ca> 
To: Sean Leonard 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents?
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: Fri, 21 Jul 2017 12:29:07 -0000

On Jul 21, 2017, at 12:38, Sean Leonard  wrote:
>=20
> Michael, the underlying concern/fear that I have about this CDDL work, =
remains that despite it being nascent, people will immediately complain =
that such-and-such features of CDDL can never change because they =
already wrote stuff.=20

There is much less of a problem defining a CDDL 2.0 than would be for an =
on-the-wire protocol.

Still, a need for that is not yet known, so I also don=E2=80=99t see it =
happen very soon.

> Better to get it right, and that means, at this stage, that all =
features of the language are up for grabs.

That is not the intention of the charter and not what the people who =
pushed for completion of this work want.

It is not like CDDL was freshly invented =E2=80=94 much of it is derived =
from ABNF, which has been around since 1978.  The way =E2=80=9Cgroups" =
are used to define arrays and maps is an innovation, but it seems to =
have worked quite well for a number of specification projects a couple =
of years already.

Of course, all those features can and should be discussed in the WG =
process =E2=80=94 that=E2=80=99s why we are going through this. =20
But when that=E2=80=99s done, it=E2=80=99s done, and the document should =
then be standards-track.

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


From nobody Fri Jul 21 06:05:31 2017
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 2AB25131C23 for ; Fri, 21 Jul 2017 06:05:30 -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 s30Sh-gOVFJp for ; Fri, 21 Jul 2017 06:05:29 -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 0A5DA131BFA for ; Fri, 21 Jul 2017 06:05:28 -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 v6LD5LjQ022610 for ; Fri, 21 Jul 2017 15:05:21 +0200 (CEST)
Received: from client-0032.vpn.uni-bremen.de (client-0032.vpn.uni-bremen.de [134.102.107.32]) (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 3xDWG93Z5Rz3ZS4; Fri, 21 Jul 2017 15:05:21 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
X-Mao-Original-Outgoing-Id: 522335120.699776-63f768f571696e77c61a6b93d1d87746
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 21 Jul 2017 15:05:20 +0200
Message-Id: <67DC043C-40C6-4850-9F54-5FE4302413E6@tzi.org>
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [Cbor] .regexp: s/PCRE/JavaScript REs/?
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: Fri, 21 Jul 2017 13:05:30 -0000

Should we replace saying that the regexes are PCRE with saying they are =
ECMA262?
Or is any other flavor (that we could be referencing) in favor?

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


From nobody Fri Jul 21 06:42:28 2017
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 CE4F1131DB6 for ; Fri, 21 Jul 2017 06:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UgttZ-I-e2Ro for ; Fri, 21 Jul 2017 06:42:25 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D906D131723 for ; Fri, 21 Jul 2017 06:42:24 -0700 (PDT)
Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 3B40A1F8F6; Fri, 21 Jul 2017 13:42:23 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0FA021662; Fri, 21 Jul 2017 15:42:14 +0200 (CEST)
From: Michael Richardson 
To: Sean Leonard 
cc: "cbor\@ietf.org" 
In-reply-to: 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> <2531.1500631522@dooku.sandelman.ca> 
Comments: In-reply-to Sean Leonard  message dated "Fri, 21 Jul 2017 03:38:18 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 21 Jul 2017 15:42:14 +0200
Message-ID: <13903.1500644534@dooku.sandelman.ca>
Archived-At: 
Subject: Re: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents?
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: Fri, 21 Jul 2017 13:42:27 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Sean Leonard  wrote:
    > Michael, the underlying concern/fear that I have about this CDDL work,
    > remains that despite it being nascent, people will immediately compla=
in
    > that such-and-such features of CDDL can never change because they
    > already wrote stuff.

I very very very strongly disagree.
They can't complain, because they will have referenced the previous RFC in
their document.  CDDL *itself* is not bits on the wire.

Any tools that are created can easily (and SHOULD) have an --rfcXXXX option,
or perhaps we want to put "version rfcXXXX" as a clause in the file.

    > Better to get it right, and that means, at this stage, that all
    > features of the language are up for grabs.

I strongly disagree.
We have a free hand.

    > (By the way, are there IETF 98 meeting minutes? I can=E2=80=99t find =
minutes
    > from IETF 98 based on quick Google and mailing list searches.)

98?  or 99?
There are meetecho records if there were no minutes posted to the list.

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        | network architect=
  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [


=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJZcgS1AAoJEJVM4Vb9/EKQoKMH/iXQfxT/XXFJPAYjAC3F1ruQ
gI3n0w1JuWSQi7R0Ih8AIBouKbYQNoPdrX6tF3Z8ZVj3F0u76V/BVjgQJ9brp3Fc
8dtstOFcBpMoUjr+TuNw7uzMKDvBP5vd2y5QAlN1jB9OR6bpbo1CNh9eKiN/qD74
QydkHFnMv3M3RrWxdrJF1o9tFuXKTD9i2GIqyPOV9ejKJTsvApBnv6IlWdMSjvDB
UyQtsFPx3ezvgcNr4scY0giNFfx7768k4ioXF9LhW5E0ilCLcBF41Y0Qv0OQlHVk
YDGefPAnvWeqSmIVhtSSncFloIwDLpLe32b9izX3bVXlrJ7vLpdtFdP6cr/ACOM=
=gHC6
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Jul 21 13:22:18 2017
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 4521212009C for ; Fri, 21 Jul 2017 13:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6DRBP0cnR6v for ; Fri, 21 Jul 2017 13:22:14 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 77B9D12711E for ; Fri, 21 Jul 2017 13:22:14 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id s4so32756861pgr.5 for ; Fri, 21 Jul 2017 13:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8Y8EEJE1DBXrnlcSqdGI78VUdmzYvwM1M++lUSS9HNM=; b=CFdFhQ1aNREuOvTcQsSyapb9XC0lkITHB6Jx4pl+pqyhn2157UF/NH5lk8Vap0iD7E EpTQEqcV7xUs2QzTnL17c0aQs91H1DWZ1Uv+7fLgcS8urF5+y1VfvgjwVDb3xTxcOIPT FCioilNpQiNISi9hQi72oQmsaRhTAyl78++26Ok3t7sSScdCGYfJ9NBDlU+b2ZWZCH6d Vm6JKFwUOFLGypzq1Jf98jyjyXrONWFuBotAutxVDuqWDmCsr6OM+KqXfQVxZz0ldTMT 2jOMPBLjsJQ9qMurwATUVjHRvaSVRWDMeaCBwGrK3GrPRfzsixyw99iIAYgqi2SCxxqL J+LA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8Y8EEJE1DBXrnlcSqdGI78VUdmzYvwM1M++lUSS9HNM=; b=ZZ7zYPNEBLgveyqjXyF4oQ/Z8OoQMnjAnPQSVDYa3X6CuMGBX7ZLiOh9FK/yDD7b70 K14prz3k1mYYMT+NR9XTEi3qrbZP6JvGHfij2xEyfj1U9nVf0wAoo7pFwWdkfEScNIoD JzOsTs1Y7hwBe5pcUSYRcYNxR2aBsMCSvUnckEY4Ph9fSZjUAOgsQDFts8jLvjYYfPOa c/5We2j7AbZrqxs2VBaZefx7C3SW9dWkEdRzw3tP9I164X7jGAaRoVF0zDI1GWqqyhLd YqYOt2fWfwViFmN2WAJZ7w41hdi+pVMcADtF1kPCfGs0SJfF7qUeFaG4i/No1kY3h5Jj xr3w==
X-Gm-Message-State: AIVw110stCc3+nlVAkUuhAp2ri/m4s25RrOpT+n1yO/jzJ1PXFbfTKBH 9fl1zS49n8w/Aw==
X-Received: by 10.99.42.141 with SMTP id q135mr8455219pgq.175.1500668534029; Fri, 21 Jul 2017 13:22:14 -0700 (PDT)
Received: from ?IPv6:2406:e007:4a2d:1:28cc:dc4c:9703:6781? ([2406:e007:4a2d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q130sm4117695pgq.51.2017.07.21.13.22.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 13:22:13 -0700 (PDT)
To: Michael Richardson , "cbor@ietf.org" 
Cc: Sean Leonard 
References:  <2FBE4C5B-2661-437A-883F-4F6E7FFBF204@seantek.com> <432f706c-dfab-0dd9-60c5-f761a1a95f67@gmail.com> <6B06F9C0-8002-4FB6-AF01-8C049C0FE7BB@seantek.com> <2531.1500631522@dooku.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 22 Jul 2017 08:22:19 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <2531.1500631522@dooku.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Cbor] Does CDDL need to be standards track to be referenced normatively by standards track documents?
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: Fri, 21 Jul 2017 20:22:16 -0000

On 21/07/2017 22:05, Michael Richardson wrote:
>=20
> Between starting this email, and pushing send, I went to find RFC-edito=
r.
> She happened to be sitting with the AD responsible for GRASP.  Both sai=
d
> that the downref would be permitted only when the use of CDDL was very
> loose.  Otherwise, it would be a problem.

Actually that's an IESG decision. But why we'd contort ourselves in that
way is beyond me.

     Brian

>=20
> I feel strongly that we need it to be standards track.
>=20
> Sean Leonard  wrote:
>     >     It's needed now. The IESG just approved at least one draft th=
at has
>     > it as a normative reference. How else do you plan to precisely sp=
ecify
>     > CBOR message formats?
>=20
>=20
>     > =E2=80=9CNeed=E2=80=9D is a very subjective word. It is nice to h=
ave. It is better to
>     > have a stable reference. But =E2=80=9Cstable references=E2=80=9D =
are also harder to
>     > make technical changes to as more people rely on it and come up w=
ith
>     > arguments for how things can never change because they already
>     > wrote/deployed stuff.
>=20
> This doesn't matter for CDDL the way it does for, i.e. IPv6.
>=20
> A specification is going to reference a *SPECIFIC* version of CDDL, and=

> it just fine if we make changes in a new version.  We do need an annota=
tion
> for the compilers/checkers/, etc. what version they should process, but=

> for the purposes of referencing CDDL, we do not have to worry if
> it changes afterwards.
>=20
>     > It=E2=80=99s not just the documents that reference this one: it=E2=
=80=99s also the
>     > documents that CDDL references. By way of example, CDDL depends o=
n
>     > regular expressions, and specifically calls out PCRE. PCRE is gre=
at but
>     > is in no way a Standard; it=E2=80=99s a single implementation. Th=
ere is a lot
>     > of variation in regular expression engines, and the most useful o=
nes
>     > (thinking about PCRE, Python, Perl, and .NET) are not SDO
>     > standards. There are some features in this draft that have not ev=
en
>     > been implemented yet.
>=20
> The lack of a specification for PCRE sounds like a more serious problem=

> regardless of the status we intend for the document.
>=20
>     > For now, you can precisely define your CBOR message format using
>     > prose. Or you can use some combination of CDDL and prose. Just
>     > reference CDDL informatively.
>=20
> That just isn't useful.
> If you tell us to use prose, then our next step will be to write a
> specification so that we don't have to be so imprecise.
>=20
> --
> ]               Never tell me the odds!                 | ipv6 mesh net=
works [
> ]   Michael Richardson, Sandelman Software Works        | network archi=
tect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rai=
ls    [
>=20
>=20
>=20
>=20
>=20
>=20
> --
> Michael Richardson , Sandelman Software Works
>  -=3D IPv6 IoT consulting =3D-
>=20
>=20
>=20


From nobody Mon Jul 24 00:19:30 2017
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 343CA127B73 for ; Mon, 24 Jul 2017 00:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 tf7Uk80nOdzh for ; Mon, 24 Jul 2017 00:19:27 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 8EEBE12441E for ; Mon, 24 Jul 2017 00:19:27 -0700 (PDT)
Received: from [192.168.123.171] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 444A4509B8; Mon, 24 Jul 2017 03:19:26 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Leonard 
In-Reply-To: <67DC043C-40C6-4850-9F54-5FE4302413E6@tzi.org>
Date: Mon, 24 Jul 2017 00:19:24 -0700
Cc: cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67DC043C-40C6-4850-9F54-5FE4302413E6@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [Cbor] .regexp: s/PCRE/JavaScript REs/?
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, 24 Jul 2017 07:19:29 -0000

At the technical (substantive) level, I think that PCRE is an excellent =
choice. The only thing lacking is identifying the version (or =
intentionally not, instead declaring it a =E2=80=9Cliving standard=E2=80=9D=
 =F0=9F=8C=8A).

First of all it=E2=80=99s already in RFC 7049, so it=E2=80=99s already =
part of CBOR. I think of PCRE like grep: a generally-available utility =
that became (or is becoming) a de-facto standard. Now grep is in the =
POSIX standard, but it wasn=E2=80=99t always that way.

PCRE(2) is better than ECMA262 since ECMA262=E2=80=99s regular =
expressions lack look-behind, named groups, and other awesome things. =
PCRE(2) also features just-in-time compiler support, so in theory it =
should be possible for an implementer to take a static regular =
expression (i.e., the kind proposed in CDDL) and shrink it down for =
embedded devices, rather than embedding the whole library.

At a process level for IETF standards documents, PCRE is problematic. I =
feel that this can be worked around/through in light of the technical =
merits=E2=80=94I just don=E2=80=99t know how to get the IESG to say =
=E2=80=9Cyes=E2=80=9D. :^)

Section 1.2 of draft-seantek-mail-regexen-02 has discussion of the =
alternatives. It also mentions POSIX Extended Regular Expressions, which =
are in Chapter 9 =E2=80=9CRegular Expressions=E2=80=9D of Base =
Definitions. They are less full-featured than ECMA262, which means in my =
view, less good. But fewer features mean easier to implement on =
constrained devices.

Sean

PS PCRE(2) is BSD-licensed, so someone could, conceivably, copy the =
entire source code into an RFC and call it a day.

> On Jul 21, 2017, at 6:05 AM, Carsten Bormann  wrote:
>=20
> Should we replace saying that the regexes are PCRE with saying they =
are ECMA262?
> Or is any other flavor (that we could be referencing) in favor?
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor


From nobody Mon Jul 24 00:37:22 2017
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 004A712441E; Mon, 24 Jul 2017 00:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioAkF6vuzJoU; Mon, 24 Jul 2017 00:37:18 -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 6ECBB131C26; Mon, 24 Jul 2017 00:37:17 -0700 (PDT)
X-AuditID: c1b4fb30-aeec49c000001664-58-5975a3ab1689
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.E9.05732.BA3A5795; Mon, 24 Jul 2017 09:37:15 +0200 (CEST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 24 Jul 2017 09:37:14 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y0zrGCy1QHqiK565n0snOlMLJTx/x5uIDcCPjds+HjU=; b=AfBr+HuDpgUhoYCcAPBFjOPto8mBqWs1GVZT1f19lp1T8JXjwhpy7bi3Jg/ze28kATFV4I/Wq0F+JVpFxu0M85bu2LXFr6BbowW8f+m9VTahE4qVM/MU2RZ7MKkTpitmTpwiviUVCds0Ym78HHfVmWuhFHWGjKSEkegfJvEK+yY=
Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB1801.eurprd07.prod.outlook.com (10.167.246.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 24 Jul 2017 07:37:13 +0000
Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::1474:2dc7:d0ec:7d9a]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::1474:2dc7:d0ec:7d9a%17]) with mapi id 15.01.1304.011; Mon, 24 Jul 2017 07:37:13 +0000
From: Francesca Palombini 
To: "cbor@ietf.org" 
CC: "cbor-chairs@ietf.org" 
Thread-Topic: =?utf-8?B?8J+UlCBDb25maXJtYXRpb24gY2FsbCBmb3IgV29ya2luZyBHcm91cCBBZG9w?= =?utf-8?Q?tion_for_draft-greevenbosch-appsawg-cbor-cddl?=
Thread-Index: AdL1cdNAE+Oa5k9GSgKtnPjDmRW2CAMgoifQ
Date: Mon, 24 Jul 2017 07:37:13 +0000
Message-ID: 
References: 
In-Reply-To: 
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.84]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB1801; 7:UTTF5mdmW7kD+Ed6eBffPnR5hAEyS7TgSsdjKKxJmoKLX+Ydd6VeuK7QYvRy7GjF/FZs8jSu5edt7jT3bY/5GddDGeDn+JmNG/o0DZsrETr241kUPuinahiAaLhZLGEVroHpaIOg0JKQgU59rz5jKOHOdROd6u230rH0x7POZukXRr9//kENtiqEULwk4GlqaYVY/xvU+mzSS6WUsrPlBNu7clffYl4S04aoBniSm0My2w/9msgZrK4s2tfc/xPdjcqj8REaNgCMEeta+NdLLQHIf4McQopEZ0+facyrb9PF2m/jQXCw+eKT/Jx//TjQbxrHn60blscBU3NhQ3url/lT9KbkPYv+g/Bk8ug7GpU70rlkDAQWdOpTsNtRd4E8QeiwSQNEO8xlx0u3pqvNQhrdChSevWbOifzRSSXTS3uNxmTZmBHmZRQbGw7j+lxjPo3yNS5Q8mJqYMVHgrKWELlnXc0CZZq6tQLBee36NjivohV0Y3Ck/gpbCewgqEj/7ZpiC+RIotoG/UpwRdlDBAjng5qKIEyUzr/4dU5D1CayIQSfOdV+Z6Brfgkrj6S9rkdPDIndMdRDlE/joMtFXFP/TVzzUVMttcz2qmaI3PK+DJlBOGfL3FdI1spF/yH+ADmt0ktHOfcBBpeJWGtyJ9TlHt8KTzIobkYHduAZbczUvraA4Ygi1BgUh03+05kDBvNAiRK38ePPd64kLLSXvoiw7OCMQlukoDlNswnL6YEf7Iv43SLm3IxfwyUKr5OTkBtS+ReubWlIMirEJ7zij9ALHg3yls7RRuH9aU5gZYM=
x-ms-office365-filtering-correlation-id: ba3c915f-31b5-4d2e-9568-08d4d266cd15
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB1801; 
x-ms-traffictypediagnostic: HE1PR0701MB1801:
x-exchange-antispam-report-test: UriScan:(37575265505322)(100405760836317)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB1801; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB1801; 
x-forefront-prvs: 0378F1E47A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39850400002)(39410400002)(39400400002)(39840400002)(189002)(199003)(53754006)(2501003)(5250100002)(2351001)(106356001)(105586002)(229383001)(2906002)(3280700002)(3660700001)(7696004)(966005)(66066001)(14454004)(54356999)(76176999)(50986999)(101416001)(74316002)(606006)(5630700001)(68736007)(5660300001)(33656002)(102836003)(3846002)(6116002)(790700001)(53546010)(189998001)(97736004)(99286003)(55016002)(2950100002)(6916009)(7736002)(236005)(6306002)(9686003)(54896002)(8936002)(1730700003)(81156014)(81166006)(86362001)(19609705001)(5640700003)(4326008)(6506006)(110136004)(6246003)(229853002)(38730400002)(450100002)(2900100001)(53936002)(25786009)(230783001)(478600001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB1801; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2539F2DC6D462035790AD4B198BB0HE1PR0701MB2539_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 07:37:13.3917 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1801
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOzjkuV2/z9qQNbKFklpfhBwMRFcySCr8U2gWdelJJNztT ce3LFIVUTI2FbnnNabJBlk2SMm2aWWBpEQaZH7SFrlVCiWFqtO0Y+O33PP//c3t5GUJiEgYy BcoSllMqCmWUiDSkPwo6aukuzYiabJfG3t6yoljD9WYyQXDCZFoXpKHzorhctrCgjOUi47NE +fcMZlRsTirfmGJ0aDihFnkxgGNA1zRA1iIRI8HPEVRP99F88BKBZXVY6A5IXE/A/GgFxSvt AnhTMyjggyUEo0NTyN2MwnEws7AidLMvPgi39OOuCoYhcDSsD191+31wPwKrs8pT7ItvImi2 dlN8gRxsthu0m0kcAl9W2jwsxlng1P3wNJW4eKLmu8fvhRWgb9ki3YywFFYrLISbCRwAH+0d Av46DKbhaYJnP3B8/ivk/Tnwfo6fBTgYvtbpKJ6l8K6jDrmXA7xIwayhb1s4DV3GVYIX7AL4 s2lHvHAEeqyVnjMBX4AGRzKfVoF50brd6IUQzPPPtqfth/rOJ0Ke1yhYuxPaiMKNOxbnWQXr Fb9oo+cB9sIrg500el4yDPofR/KWA6CvW6B5PgTVrW30znwnos3IT82qs4vy5PIIlivIUatV ygglWzKAXH/HZt2IGkKOpcQxhBkk8xbP1pdmSISKMrWmaAwBQ8h8xZ2cKyXOVWiusZwqkyst ZNVjKIghZQHixJGZdAnOU5SwV1i2mOX+qwLGK1CHdiVLtR/CU+5XNhhb6HL/B3satAZ/52uq NTd4qLtRoZo6tkxqjk+c9IFzSUZtQM+lpLtm/Xhz76d4X8JBm+eqslM1mozUXu5tzMx0WUha ptZ7PPSiqOvMUtXg6Ub5z5RT9G7VwJRlRG7ULqdMXt58+tv2sGmM6dr3TRu24TwrI9X5iujD BKdW/ANHskrANwMAAA==
Archived-At: 
Subject: Re: [Cbor]  =?utf-8?q?=F0=9F=94=94_Confirmation_call_for_Working_Grou?= =?utf-8?q?p_Adoption_for_draft-greevenbosch-appsawg-cbor-cddl?=
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, 24 Jul 2017 07:37:20 -0000

--_000_HE1PR0701MB2539F2DC6D462035790AD4B198BB0HE1PR0701MB2539_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpUaGUgZGVhZGxpbmUgaGFzIHBhc3NlZCwgYW5kIGZyb20gbGlzdGVuaW5nIHRv
IHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZyBhbmQgbWFpbGluZyBsaXN0LCB0aGUgZHJhZnQgaXMg
YWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cC4gTW9yZW92ZXIsIEkgaGVhciBhIG1ham9yaXR5
IG9mIHBlb3BsZSAoaW5jbHVkaW5nIG91ciBBRCkgYWdyZWVpbmcgb24gdGhpcyBiZWluZyBjaGFu
Z2VkIHRvIHN0YW5kYXJkIHRyYWNrIHJpZ2h0IGF3YXkuDQoNClNvLCBhdXRob3JzOiBwbGVhc2Ug
cmVzdWJtaXQgYXMgZHJhZnQtaWV0Zi1jYm9yLWNkZGwgYW5kIGNoYW5nZSB0byBzdGFuZGFyZCB0
cmFjay4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCkZyb206IEZyYW5jZXNjYSBQYWxvbWJpbmkg
W21haWx0bzpmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbV0NClNlbnQ6IGRlbiA1IGp1
bGkgMjAxNyAxMTo0OA0KVG86IGNib3JAaWV0Zi5vcmcNCkNjOiBjYm9yLWNoYWlyc0BpZXRmLm9y
Zw0KU3ViamVjdDog8J+UlCBDb25maXJtYXRpb24gY2FsbCBmb3IgV29ya2luZyBHcm91cCBBZG9w
dGlvbiBmb3IgZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsDQoNCkhpIGFsbCwN
Cg0KQXQgdGhlIElFVEY5OCBtZWV0aW5nLCB3ZSBoYWQgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRv
cHQgZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsIGFzIGEgc3RhcnRpbmcgcG9p
bnQgdG8gd29yayBvbiBDQk9SIGRhdGEgZGVmaW5pdGlvbiBsYW5ndWFnZS4gVGhlIGF1dGhvcnMg
aGF2ZSBub3cgdXBkYXRlZCB0aGUgZG9jdW1lbnQgYW5kIGZlZWwgdGhpcyBpcyByZWFkeSB0byBi
ZSBhIHdnIGl0ZW0uDQoNClRoaXMgaXMgYSBjb25maXJtYXRpb24gY2FsbCBmb3IgYWRvcHRpbmcg
dGhpcyBkcmFmdCBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4gSWYgeW91IGRvIG5vdCBhZ3JlZSB3
aXRoIHRoZSBpbi1yb29tIGNvbnNlbnN1cyB0aGF0IHdlIGhhZCBpbiBDaGljYWdvIHRvIGFkb3B0
IHRoaXMgYXMgYSBXRyBkb2N1bWVudCwgcGxlYXNlIHNwZWFrIHVwIHVudGlsIDIwMTctMDctMTku
IElmIHlvdSB3ZXJlbuKAmXQgaW4gdGhlIHJvb20gYnV0IGRvIGFncmVlIHdpdGggYWRvcHRpbmcg
dGhpcyBkb2N1bWVudCwgeW91IGNhbiBhbHNvIHRlbGwgdXMuDQoNCmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwtMTENCg0KVGhh
bmtzLA0KRnJhbmNlc2NhDQo=

--_000_HE1PR0701MB2539F2DC6D462035790AD4B198BB0HE1PR0701MB2539_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z
ZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vn
b2UgVUkgU3ltYm9sIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHls
ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h
bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N
c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s
bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z
b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu
MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj5IaSBhbGwsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZWFk
bGluZSBoYXMgcGFzc2VkLCBhbmQgZnJvbSBsaXN0ZW5pbmcgdG8gdGhlIGZhY2UtdG8tZmFjZSBt
ZWV0aW5nIGFuZCBtYWlsaW5nIGxpc3QsIHRoZSBkcmFmdCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3Jr
aW5nIGdyb3VwLiBNb3Jlb3ZlciwgSSBoZWFyIGEgbWFqb3JpdHkgb2YgcGVvcGxlIChpbmNsdWRp
bmcgb3VyIEFEKSBhZ3JlZWluZyBvbiB0aGlzIGJlaW5nIGNoYW5nZWQgdG8gc3RhbmRhcmQgdHJh
Y2sNCiByaWdodCBhd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgYXV0aG9yczogcGxl
YXNlIHJlc3VibWl0IGFzIGRyYWZ0LWlldGYtY2Jvci1jZGRsIGFuZCBjaGFuZ2UgdG8gc3RhbmRh
cmQgdHJhY2suPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF
MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPkZyb206PC9iPiBGcmFuY2VzY2EgUGFsb21iaW5pIFttYWlsdG86ZnJhbmNlc2NhLnBhbG9t
YmluaUBlcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDUganVsaSAyMDE3IDEx
OjQ4PGJyPg0KPGI+VG86PC9iPiBjYm9yQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBjYm9yLWNo
YWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2VyaWYiPiYjMTI4Mjc2Ozwvc3Bhbj4gQ29u
ZmlybWF0aW9uIGNhbGwgZm9yIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gZm9yIGRyYWZ0LWdyZWV2
ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhlIElFVEY5OCBtZWV0aW5nLCB3ZSBo
YWQgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ct
Y2Jvci1jZGRsIGFzIGEgc3RhcnRpbmcgcG9pbnQgdG8gd29yayBvbiBDQk9SIGRhdGEgZGVmaW5p
dGlvbiBsYW5ndWFnZS4gVGhlIGF1dGhvcnMgaGF2ZSBub3cgdXBkYXRlZCB0aGUgZG9jdW1lbnQg
YW5kIGZlZWwgdGhpcyBpcyByZWFkeSB0byBiZSBhIHdnIGl0ZW0uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoaXMgaXMgYSBjb25maXJtYXRpb24gY2FsbCBmb3IgYWRvcHRpbmcgdGhpcyBkcmFm
dCBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4gSWYgeW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBp
bi1yb29tIGNvbnNlbnN1cyB0aGF0IHdlIGhhZCBpbiBDaGljYWdvIHRvIGFkb3B0IHRoaXMgYXMg
YSBXRyBkb2N1bWVudCwgcGxlYXNlIHNwZWFrIHVwIHVudGlsIDIwMTctMDctMTkuIElmIHlvdSB3
ZXJlbuKAmXQgaW4gdGhlIHJvb20NCiBidXQgZG8gYWdyZWUgd2l0aCBhZG9wdGluZyB0aGlzIGRv
Y3VtZW50LCB5b3UgY2FuIGFsc28gdGVsbCB1cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBz
YXdnLWNib3ItY2RkbC0xMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyZWV2
ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbC0xMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJhbmNlc2NhIDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_HE1PR0701MB2539F2DC6D462035790AD4B198BB0HE1PR0701MB2539_--


From nobody Mon Jul 24 02:06:27 2017
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 DCF1E12EACC; Mon, 24 Jul 2017 02:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqHUdzPnqa3R; Mon, 24 Jul 2017 02:06:23 -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 F1BE9129ACD; Mon, 24 Jul 2017 02:06:22 -0700 (PDT)
X-AuditID: c1b4fb3a-bea2a9c000001b2f-ab-5975b88df8ff
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.BD.06959.D88B5795; Mon, 24 Jul 2017 11:06:21 +0200 (CEST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 24 Jul 2017 11:06:20 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2JryE3HZMoNfykB3efthRCB3bqxR7BqYSBBq6gMG1zk=; b=OPJZNCD5viy/vK1njl1YDu8/0ykqxSHjtDHLKfLb2XAiE464PK5QZKlpLzXiwVB9lQswhWK3jwc37W6tqD0BLVCmjQSiMXHIF9DYb74MlfuhrjPTjDx2BlYyC1gto5IkTpKMAJNfP/AlWAiDuNZI+WE0M5PFC/5yHVR0rJi+UkY=
Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2298.eurprd07.prod.outlook.com (10.168.127.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 24 Jul 2017 09:06:18 +0000
Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::1474:2dc7:d0ec:7d9a]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::1474:2dc7:d0ec:7d9a%17]) with mapi id 15.01.1304.011; Mon, 24 Jul 2017 09:06:18 +0000
From: Francesca Palombini 
To: "cbor@ietf.org" 
CC: "cbor-chairs@ietf.org" 
Thread-Topic: Minutes IETF99 CBOR
Thread-Index: AdMEW7qVr9Hzo/0MQQ6S2dZe1R5XZQ==
Date: Mon, 24 Jul 2017 09:06:18 +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.84]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2298; 7:hwnY4i29IKTGwocpI+hNlZn+CblBcN2xrlDFm/RNW7ObgklB6WWg7rLYyw3J5S/AQSpTEusgoYzHI3fMC9hxpdSsMKuApBkooqbnSQYGyB5Xka8AFQfDearEgRDOG7aZ09YfQ6Rsx8vASmd8HGUd5NHB7Sqg7kBWRM0rLdX+d0ljGij29II76wwOZXOoJqSKT7QZoD+7oGqR7FzbKAxj7uX2FHeG3VJc88u8Y16DhCHzNmuVf7xaUVdChjGtr4jQ/en4lT+SR1o89Ql0K1nx7rGmHrGnoJAn49b9h+bpJSde+XIKy4xgAa/cufnQlGITmSJ7siokQ6AL0vWAw4w2fG23z8UOpBSUZ6Kdfp7HQwfxPn+GWnHbDbZzjyYa9cvkoeLW6tMyHLOXTO5dP3jkC5dlwpkPZRJgjYztMiVP/VWXvNsRa0VFy89tAGgNqcpvKGCTvAEQo2q04pXZc4W10W2ZIQHrI/hSO0HO8VxfEGnaqL1a3uOqmyQyGUTeRe2TR8nSABCwBF7ua+vIc1qdBaGjcPY2fSN9h5nnFFv0Z3Pv8Yigi+svzLy6WQ91g7vB8b9zHR62eVzuhzA5hPI6UvYsyJ135i5lT9eoRxEyL43MWaBZBvd44AvA00uZEuxedO/Z1kUVd4YnZ/PFFcC9amfMsnKN3UU0Veeq+L8m+X2LbncgZXJ/PSkCnyqqZ4kK35+qM/cLqdP1q2EM3kll7Dmh3MBelFA5JfmNa2PlWzT8aTqlVCYa5bd62zHByY2k2NtJNUOjV332XYtizdNWt2/2MESJpnyb7Ew77LO9Ut8=
x-ms-office365-filtering-correlation-id: a264cc80-2297-4b34-f4a2-08d4d2733eba
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB2298; 
x-ms-traffictypediagnostic: HE1PR0701MB2298:
x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2298; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2298; 
x-forefront-prvs: 0378F1E47A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(39860400002)(53754006)(189002)(57704003)(199003)(561944003)(2900100001)(478600001)(97736004)(8676002)(1730700003)(5250100002)(102836003)(3846002)(790700001)(6116002)(345774005)(101416001)(6436002)(2501003)(5640700003)(25786009)(8936002)(7736002)(81166006)(81156014)(19609705001)(6916009)(86362001)(50986999)(54356999)(189998001)(99286003)(6306002)(33656002)(966005)(68736007)(2351001)(55016002)(2906002)(3280700002)(54896002)(5660300001)(236005)(106356001)(6506006)(66066001)(110136004)(38730400002)(7116003)(9686003)(14454004)(4326008)(53936002)(606006)(105586002)(7696004)(74316002)(5630700001)(3660700001)(450100002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2298; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2539A1A08A36919A86984B2998BB0HE1PR0701MB2539_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 09:06:18.0656 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2298
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0gUURTHuzOzs6O0cNvWPJiirQSVuqUISUiYhAYlRBT4QHLRSaV1x2ZU 0r5oKpq2lqmYD9DNxWc+KktDLV2lBwpa2ocyQfOFighpksRqjlfBb7/z/59zD+fP5Wh1rcKJ izcm8aJRb9Cy9kxZaIeDl6kzOezMwx7sV2FrR35luaVMAHXJYtmgrqJwe/8Y3hCfwounz0fZ x71ZN1GJjaXo7lZ9AZWOijJQHrLjAPvCelMnm4fsOTUeQPBxtURJik8IZtsyGLlgsIkGi7Wc Jk4FBQ2WyZ15NZ5HkLecJjOL/WFkakUhswa7Q0lx//a7HEdjb9joviPLh7Ez1NhKKFnW4GMw VRNIunUw05HFyszg49Ay28zIrMJRUPy3hpYZYRdYy2jaYRo7wo+ZKopcgMHSPUwTdoCF6U0F 6Y+GsfECJdHdYDE/nSXsAl+r8pF8CuBfLDxpfbbbFAKLq2aWGKMUND0q3M3IE8bXzLvbLoO1 u09BWIDOcbOSDHxQwERO3e4KZzBVdymIscRCY1MHRdLioa45G5EonGBi7AF6jE6W7zuJsAAr ud+V5TsRHILPZTMM0T2huus3S9gDas1L9B4P9U5T+/VqpGxEDhIvSQmxPj46XoyPliTBqDPy SS/R9u/pa/93rhP1zV+wIswh7UFVTUNymFqhT5FSE6wIOFqrUVWL25IqRp+axovCTTHZwEtW dJRjtI6qgHcjoWocq0/ib/N8Ii/uuRRn55SO7p84wI+q58yZOp0YFRKru2ESbIH3lJ59QUFD RsGm/xZZr7t10X0g68vm5IuzKYV/soJ5J8/rc4ODHq6Rvu8FYzCX6ePa/8ptM1SobHmbXdTa m5fTFlzV87phOcjg/jyiaPinrXB+oCA1PCJmqKsSHfFYuPa0TtBUXXExeW3FahkpTu99ihYl /X8PYPqQOQMAAA==
Archived-At: 
Subject: [Cbor] Minutes IETF99 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: Mon, 24 Jul 2017 09:06:26 -0000

--_000_HE1PR0701MB2539A1A08A36919A86984B2998BB0HE1PR0701MB2539_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Thank you for a very interesting meeting in Prague.
Here below you can find the minutes for the second CBOR meeting. Thanks a l=
ot Paul for taking them!

Please let us know if you have any comment, as soon as possible, and no lat=
er than 2017-09-03.

Thanks,
Francesca

CBOR WG minutes
IETF 99 - Prague
Monday, July 17, 2017, 15:50 - 17:20
Chairs: Joe Hildebrand, Francesca Palombini Acting chair: Matthew Miller Mi=
nutes taken by Paul Hoffman, Francesca Palombini
    Text from the slides is not reproduced here; only differences and addit=
ions
    See https://datatracker.ietf.org/meeting/99/session/cbor for slides

CBOR specification status: Carsten
    https://tools.ietf.org/html/draft-ietf-cbor-7049bis-00

    * About tag registry (sl. 5)
    Michael Richardson: If you want to put a circuit breaker in, you need t=
o redefine the second half ot the space to have expert review with differen=
t criteria. Two experts criteria ranges.
    Carsten: Good point, let's take that offline.

    * About implementations (sl. 8)
    ?: IPFS uses CBOR, so we should find out which library it uses
    Carsten: True for other protocols.
    Call to action: Look at the wiki page and send comments on the list abo=
ut implementation features.

    * Which implementations (sl. 10)
    Francesca: Let's start with defining the most used/common libraries. Pl=
ease start the discussion to the mailing list.
    Alexey: to clarify, any feature you have to have 2 independent implemen=
tation, no need to be the same implementations. 4 or 5 implementations coul=
d cover this.
    Paul: do we need to show uses of each tag?
        Alexey: Go ahead, fill in the table, find the gaps and later decide=
 if they are unused features, if they greatly increase implementation compl=
exity, separate document or not.
    Sean Leonard: what does "implementation" mean? Because you can tag anyt=
hing with anything in CBOR...does it have to validate? reject non-conformin=
g data?
    Carsten: hopefully we don't have to define conformity.

    Francesca: Start with what Alexey has said, then go to the list about t=
he tag issue. Timeline?
    Carsten: end of September we should be done.

    Call to action: Please do comment on things that are unclear, even edit=
orial, use the github or mailing list

    Carsten: from offline discussion: CBOR document doesn't say what kind o=
f Unicode you find in UTF-8 strings
        Clear that it has to be valid UTF-8
        People might have different views of what other restrictions there =
should be

    Francesca: any other comment, take it to the list.

CDDL: Carsten
    https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11

    * Status (sl. 13)
    Alexey: Put this on Standards Track

    * Name change (sl. 14)
    Francesca (chair hat off): If we do keep the name, liked keeping the na=
me with "CBOR"

    * Comments
    Jeffery Yasskin: Wants to be able "parse these bytes with CDDL", that's=
 not precisely defined in current spec. Would be nice to have that.
        Carsten: mabye need to add a syntax tree. Also think useful but may=
be a different project. Let's fix the acceptance part

    Carsten: When do we want to be done? Hope this to be the last round. WG=
 last call before Singapore.

    Francesca: Any strong objections to moving this to standards track?
    Sean Leonard: has concerns about standards track because the document i=
s changing too much
    Joe Hildebrand (chair hat on): wants to nail the name nailed down befor=
e we go too far
    Francesca: let's discuss the name offline, let's take the discussion on=
 the mailing list.
    Henk: I understand one of the preconditions for the standard track is t=
he name. I see it obvious evolution rather than "innovation" in the documen=
t. Please raise in the list very soon.
    Matt: Accepting a doc as wg document doesn't mean it cannot be changed.
    Alexey: rate of change isn't that important until it is done.
        Stable means stable at the end of the discussion.
        Different discussion if it's changing or if it is standard track.
    Henk: OK, that clarifies.
    Alexey: As long as the core is stable, you can move the rest to another=
 document.

Array tags: Carsten
    https://tools.ietf.org/html/draft-jroatch-cbor-tags-05

    * Which tag length? (sl. 26)
    Joe: way too many tags. one tag with an array [type, actual array] shou=
ld work just fine.
        Carsten: Somewhat of a style question
    Sean: When I reviewed this when originally proposed last year, I was ok=
ay with the quantity of tags, but opposed to them being in the 2-byte space=
 ( < 256). In the four-byte space, no big deal.
        Carsten: some arrays will be pretty short
        Joe: sets bad precedent
        Sean: my concern with Joe's proposal is that now we need another su=
b-registry for the type "tag" (not truly a tag, it's an enumeration). So I =
agree with Carsten
        Joe: let's discuss it offline

    How many people have read? ~7
    Call for action: reviews. Paul, Jim volunteered for review.
    Call for action: discussion on which tag length.

Time tags: Carsten
    https://tools.ietf.org/html/draft-bormann-cbor-time-tag-01

CBOR Tag for CBOR Templates: Carsten
    https://tools.ietf.org/html/draft-bormann-lpwan-cbor-template-00
    Joe: had a one-tag solution

Packed Tag: Carsten
    https://tools.ietf.org/html/draft-bormann-cbor-packed-00

Sean: reminds the WG that there is the OID document and other drafts that n=
eed more review

--_000_HE1PR0701MB2539A1A08A36919A86984B2998BB0HE1PR0701MB2539_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


Thank you for a very interesting meeting in Prague.<=
o:p>


Here below you can find the minutes for the second C=
BOR meeting. Thanks a lot Paul for taking them!


 


Please let us know if you have any comment, as soon =
as possible, and no later than 2017-09-03.


 


Thanks,


Francesca


 


CBOR WG minutes


IETF 99 - Prague


Monday, July 17, 2017, 15:50 - 17:20


Chairs: Joe Hildebrand, Francesca Palombini Acting c=
hair: Matthew Miller Minutes taken by Paul Hoffman, Francesca Palombini


    Text from the slides is not repro=
duced here; only differences and additions


    See 
https://datatracker.ietf.org/meeting/99/session/cbor for slides


 


CBOR specification status: Carsten


    
https://tools.ietf.org/html/draft-ietf-cbor-7049bis-00 


 


    * About tag registry (sl. 5)=



    Michael Richardson: If you want t=
o put a circuit breaker in, you need to redefine the second half ot the spa=
ce to have expert review with different criteria. Two experts criteria rang=
es.


    Carsten: Good point, let's take t=
hat offline.


 


    * About implementations (sl. 8)


    ?: IPFS uses CBOR, so we should f=
ind out which library it uses


    Carsten: True for other protocols=
.


    Call to action: Look at the wiki =
page and send comments on the list about implementation features.


 


    * Which implementations (sl. 10)<=
o:p>


    Francesca: Let's start with defin=
ing the most used/common libraries. Please start the discussion to the mail=
ing list.


    Alexey: to clarify, any feature y=
ou have to have 2 independent implementation, no need to be the same implem=
entations. 4 or 5 implementations could cover this.


    Paul: do we need to show uses of =
each tag?


        Alexey: G=
o ahead, fill in the table, find the gaps and later decide if they are unus=
ed features, if they greatly increase implementation complexity, separate d=
ocument or not.


    Sean Leonard: what does "imp=
lementation" mean? Because you can tag anything with anything in CBOR.=
..does it have to validate? reject non-conforming data?


    Carsten: hopefully we don't have =
to define conformity.


 


    Francesca: Start with what Alexey=
 has said, then go to the list about the tag issue. Timeline?

    Carsten: end of September we shou=
ld be done.


 


    Call to action: Please do comment=
 on things that are unclear, even editorial, use the github or mailing list=



    


    Carsten: from offline discus=
sion: CBOR document doesn't say what kind of Unicode you find in UTF-8 stri=
ngs


        Clear tha=
t it has to be valid UTF-8


        People mi=
ght have different views of what other restrictions there should be


 


    Francesca: any other comment, tak=
e it to the list.


 


CDDL: Carsten


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


 


    * Status (sl. 13)


    Alexey: Put this on Standards Tra=
ck


 


    * Name change (sl. 14)=



    Francesca (chair hat off): If we =
do keep the name, liked keeping the name with "CBOR"

 


    * Comments


    Jeffery Yasskin: Wants to be able=
 "parse these bytes with CDDL", that's not precisely defined in c=
urrent spec. Would be nice to have that.


        Carsten: =
mabye need to add a syntax tree. Also think useful but maybe a different pr=
oject. Let's fix the acceptance part


    


    Carsten: When do we want to =
be done? Hope this to be the last round. WG last call before Singapore.


 


    Francesca: Any strong objections =
to moving this to standards track?


    Sean Leonard: has concerns about =
standards track because the document is changing too much


    Joe Hildebrand (chair hat on): wa=
nts to nail the name nailed down before we go too far


    Francesca: let's discuss the name=
 offline, let's take the discussion on the mailing list.


    Henk: I understand one of the pre=
conditions for the standard track is the name. I see it obvious evolution r=
ather than "innovation" in the document. Please raise in the list=
 very soon.


    Matt: Accepting a doc as wg docum=
ent doesn't mean it cannot be changed.


    Alexey: rate of change isn't that=
 important until it is done.


        Stable me=
ans stable at the end of the discussion.


        Different=
 discussion if it's changing or if it is standard track.


    Henk: OK, that clarifies.


    Alexey: As long as the core is st=
able, you can move the rest to another document.


 


Array tags: Carsten


    
https://tools.ietf.org/html/draft-jroatch-cbor-tags-05 


 


    * Which tag length? (sl. 26)=



    Joe: way too many tags. one tag w=
ith an array [type, actual array] should work just fine.


        Carsten: =
Somewhat of a style question


    Sean: When I reviewed this when o=
riginally proposed last year, I was okay with the quantity of tags, but opp=
osed to them being in the 2-byte space ( < 256). In the four-byte space,=
 no big deal.


        Carsten: =
some arrays will be pretty short


        Joe: sets=
 bad precedent


        Sean: my =
concern with Joe's proposal is that now we need another sub-registry for th=
e type "tag" (not truly a tag, it's an enumeration). So I agree w=
ith Carsten


        Joe: let'=
s discuss it offline


 


    How many people have read? ~7


    Call for action: reviews. Paul, J=
im volunteered for review.


    Call for action: discussion on wh=
ich tag length.


 


Time tags: Carsten


    
https://tools.ietf.org/html/draft-bormann-cbor-time-tag-01 <=
/p>

 


CBOR Tag for CBOR Templates: Carsten


    
https://tools.ietf.org/html/draft-bormann-lpwan-cbor-template-00 <=
/o:p>


    Joe: had a one-tag solution<=
o:p>


 


Packed Tag: Carsten


    
https://tools.ietf.org/html/draft-bormann-cbor-packed-00 

 


Sean: reminds the WG that there is the OID document =
and other drafts that need more review






--_000_HE1PR0701MB2539A1A08A36919A86984B2998BB0HE1PR0701MB2539_--


From nobody Thu Jul 27 05:08:08 2017
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 C2479131C2F; Thu, 27 Jul 2017 05:08:00 -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.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150115728074.11640.8757499481026921505@ietfa.amsl.com>
Date: Thu, 27 Jul 2017 05:08:00 -0700
Archived-At: 
Subject: [Cbor] I-D Action: draft-ietf-cbor-cddl-00.txt
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, 27 Jul 2017 12:08:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.

        Title           : Concise data definition language (CDDL): a notational convention to express CBOR data structures
        Authors         : Henk Birkholz
                          Christoph Vigano
                          Carsten Bormann
	Filename        : draft-ietf-cbor-cddl-00.txt
	Pages           : 51
	Date            : 2017-07-27

Abstract:
   This document proposes a notational convention to express CBOR data
   structures (RFC 7049).  Its main goal is to provide an easy and
   unambiguous way to express structures for protocol messages and data
   formats that use CBOR.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cbor-cddl-00
https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-00


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/