From nobody Tue Jun 2 08:56:02 2020 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 DA09E3A08F6; Tue, 2 Jun 2020 08:56:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159111336078.23563.13886927428954936511@ietfa.amsl.com> Date: Tue, 02 Jun 2020 08:56:00 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-06-03 CHANGED X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 15:56:01 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-06-03 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-10 Wednesday, June 3, 2020, 17:00 - 18:00 CEST Chairs: Francesca Palombini, Jim Schaad Webex: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 Jabber: cbor@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-cbor-10-cbor?useMonospaceFont=true Agenda: * CBOR specification status : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 * ABNF addition to CDDL : Carsten https://tools.ietf.org/html/draft-bormann-cbor-notable-tags-01 * CBOR Tag for Date : Mike https://tools.ietf.org/html/draft-jones-cbor-date-tag-01 * AoB Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 From nobody Wed Jun 3 07:25:25 2020 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 B03573A07A1 for ; Wed, 3 Jun 2020 07:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emD6d5w7PZLJ for ; Wed, 3 Jun 2020 07:25:18 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8503A05A4 for ; Wed, 3 Jun 2020 07:25:17 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49cWQg2WPLzyYv; Wed, 3 Jun 2020 16:25:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 3 Jun 2020 16:25:14 +0200 X-Mao-Original-Outgoing-Id: 612887114.930734-93b04a559ef0f8864c2a5e3717b43446 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> References: To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [cbor-wg/CBORbis] Section 7.1 and IANA considerations. (#196) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 14:25:23 -0000 I just submitted a pull request that addresses some comments on Section = 7.1, extension points. I used the occasion to pick up the idea to move the lower half of the = 1+2 tag space (256 to 32767) to specification required. Comments on this? > You can view, comment on, or merge this pull request online at: >=20 > https://github.com/cbor-wg/CBORbis/pull/196 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 3 08:03:08 2020 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 E92033A0918 for ; Wed, 3 Jun 2020 08:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8y8Yax-8rfO for ; Wed, 3 Jun 2020 08:03:04 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640129.outbound.protection.outlook.com [40.107.64.129]) (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 9A1CE3A08FD for ; Wed, 3 Jun 2020 08:03:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RcT5VnL+tgrE44F03JXe1JfNV0KflB8zpA8MhYZqzc3FYJVV4fvU7dRFojo26yFKZxzEkEtz4Fg181Y7vwyyOteL6Hfsd0ndGuJFdi2xZzk4LyB4nCVxI62uu5Z1/SFhmMIxyluSi2HmTH0vnL3oMyh2Mwi9Q1ubhHkzXF8G5xuVwmCjzCat21CRsvXmw9XnXCMfugs5+JO2YLK5yK3FzPY+bn339ozcMKXouO8vqMbWtHUCbE0Hlj3gUjq+i8gw1kcvpxvOqBzDl4kf4RiGC1/UXwuNbbgmZ+1qMMJ7fIvOaDSXN4gMSoTtTibiGn6tPODJEeo/XRCZEViZTfxvnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YiRxF2sGcvlVJNw3i7EvRvqx65fGn3/FucpVkL8LTNc=; b=d6q5dqL7WMX1xAFVcmXqszqKJpHh8HLgJFMmY8qBQRCH3H6NTiMLemfy7XI1RXWw4pGIZjktwOPjHLQrXOjAnniD3v2O5Z4u6iu6jH6UbEEJGBDTlj36B45mMtxrmgLfeS6+TTue2y0YWKZ3Soptxp5Gz3iv0d14GQutnMhoeljAiNU4ANWYeN/A24Gb83A5LGsKxRwHk2bjfZ8dnRaoZ48iTNQs4zGdBbJu1rHxiCxnUDrhMUbUrx9zMf3J5h+NTWLCdXkOeFp3dru/4QyVroX3NhCeoAwId8Lb++UQMcSUyVySDD6M28cG9eVaujnH2Jly22D2sfN1Mz19ztnwOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YiRxF2sGcvlVJNw3i7EvRvqx65fGn3/FucpVkL8LTNc=; b=bwkpBTJ5SsmOxFn1DLYkCw44LWStwjDUOeVMyfVir54eqKIogu2e4hR1zExeok1hBa8olc6TI87pOxRRTrJlMyIovOZqBbqFBR86RVov/8ESO3dceNynblNq4PEAYqqRN4QiFa1krJo7Do8RAil3a3nA4F7wvhi1KcXVXS0WqaQ= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0323.namprd00.prod.outlook.com (2603:10b6:207:1f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3104.0; Wed, 3 Jun 2020 15:02:55 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548%5]) with mapi id 15.20.3106.000; Wed, 3 Jun 2020 15:02:55 +0000 From: Mike Jones To: Carsten Bormann CC: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Anthony Nadalin Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AdY5uA3w3er6eARrTNKEyZ0rNe5zlw== Date: Wed, 3 Jun 2020 15:02:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=34bcdc4a-2e96-4be3-abd4-00002a825baf; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-03T15:00:42Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c12d539f-ca23-489a-d8ba-08d807cf3230 x-ms-traffictypediagnostic: BL0PR00MB0323: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qaRImEPEJK+MoiZrh2Kvlq55xyrGegbXs3Rqt5YMCzW3/PWxTZURpoyTJYr4YsCorlOOPXoGQJK2tmCcCW+FmIgNlaHMJ5L25/ntLIZgvOKYmpF0HuU65F6pBtEd9RSheKZluepMkO00MWWdyv3zF+/gIOfFx0+c+eFSO6l+s2evJFgWZP+2WZbfhlZP/iT8mpdtZ3ou3nWN4HdjGcbOaB8CZn4IgTtPG/XG3zzuSOZG0oyME6WRsuPbgDjRJFb76oguAP3Fx7HVSp1rlO+evSfgrffNYt5+pRfOwr8braSC977h4XtF2fpYTfByCGwLfexOzwZu/fp9nKcS1iRkxCnvrSmTNPBr5eyfSC8zTOeHTgihXu3+sVkcPWosveomWkchvTp2uOC0zuJvG1sWGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(54906003)(8676002)(66476007)(2906002)(4326008)(71200400001)(107886003)(76116006)(64756008)(66446008)(66556008)(8936002)(83380400001)(66946007)(478600001)(966005)(6916009)(33656002)(53546011)(26005)(186003)(52536014)(82960400001)(66574014)(316002)(6506007)(9686003)(5660300002)(10290500003)(8990500004)(55016002)(7696005)(82950400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +/XQw+xztQvH5YisQ1sMEEJ59hdpTBqJyghAtJ6Ezf6rBy88CvFypfy5zAiGH5rReZmWhrQTAywxy8bd3K0GcW/ZZMfEpliLLO/fh8RDO1Qpwra+NSqdanxiEk5Be4GbivJabxPqAerDPVHtEW5/fb2qWIDw++0PUg+f3v3SVqiaIT+YxGygRzTzfnAuG7iRF6NM/HfZeF/RZN7FgbcdfP63LswDyaPqPW/Y+TuwpMlxGy7eKaMJ8mhzqyhHDZ0DlBDA980iuzyhAN9B8qMi5NpXZ+7r0I4CbbUDYx/PbE8IPBctTDQOa/lrgpBIE7sgfDOb9jo615EvMufOGjwAxUHph2lVApsVwbRSXod9F1Ptj12uP4sTSjCsvoe2seml0H/4D9NMVCvp9pUcAX6nBLQJLMIRJFPJFQrAkovbebkd346plkF7UGpAy37+coP33ZHuTLIaWgxg22J04gId4Q/we618L7PNZt/BXtQb1oY= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c12d539f-ca23-489a-d8ba-08d807cf3230 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 15:02:55.3486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 28bm1eFf2jtwtoxnJwgj6el9gDKu33ZgUR9X6H+tdlVNVVutrm1CS1OxAa9izD4CT3WbB9PpEhjvXos8QCUiKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0323 Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 15:03:07 -0000 TGV0J3MgZGlzY3VzcyB3aGV0aGVyIHRvIGFkZCBhIG5vbi1ub3JtYXRpdmUgcmVmZXJlbmNlIHRv IHRoZSBNb2RpZmllZCBKdWxpYW4gRGF0ZSB0byB0aGUgZHJhZnQgb3Igbm90Lg0KDQoJCQkJLS0g TWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5u IDxjYWJvQHR6aS5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMiwgMjAyMCA3OjIyIEFN DQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6ICJSaWNo dGVyLCBKw7ZyZyIgPEpvZXJnLlJpY2h0ZXJAcGR2LUZTLmRlPjsgY2JvckBpZXRmLm9yZzsgQW50 aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogW0Nib3Jd IENCT1IgdGFnIGZvciBSRkMgMzMzOSBmdWxsLWRhdGUgdmFsdWVzDQoNCk9uZSBvdGhlciBudWdn ZXQgb2YgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBiZSB1c2VmdWwgdG8gbWluaW1pemUgY29uZnVz aW9uIGlzIHRoYXQgdGhlIHRhZy0xMDAgZGF0ZSBudW1iZXIgZm9yIGEgZGF0ZSByZWZlcmVuY2Vk IHRvIFVUQywgVEFJLCBUVCBvciBzaW1pbGFyLCBpcyB0aGUgTUpEIChNb2RpZmllZCBKdWxpYW4g RGF0ZSkgbnVtYmVyIG9mIHRoZSBkYXkgdG8gdGhlIHNhbWUgcmVmZXJlbmNlIG1pbnVzIDQwNTg3 Lg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCg0KPiBPbiAyMDIwLTA0LTIyLCBhdCAwNjoxNSwgQ2Fy c3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IHdyb3RlOg0KPiANCj4gSGkgTWlrZSwNCj4gDQo+ IHRoYW5rcyBmb3Igc3VibWl0dGluZyB0aGUgZHJhZnQhDQo+IEnigJlkIGluY2x1ZGUgdGhlIHZh bHVlIHplcm8gKGkuZS4sIDE5NzAtMDEtMDEgaXRzZWxmKSwgbm90IGp1c3QgcG9zaXRpdmUgb3Ig bmVnYXRpdmUgdmFsdWVzLg0KPiAoVGhyb3VnaG91dCB0aGUgQ0JPUiByZWxhdGVkIHdvcmssIHdl IGhhdmUgYXZvaWRlZCDigJxwb3NpdGl2ZeKAnSBhbmQgDQo+IHVzdWFsbHkgc2FpZCDigJx1bnNp Z25lZOKAnSwgd2hpY2ggaW5jbHVkZXMgemVyby4pDQo+IA0KPiBzL2FwcGxpY2FpdG9ucy9hcHBs aWNhdGlvbnMvDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiANCj4+IE9uIDIwMjAtMDQt MjIsIGF0IDAzOjI3LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBk bWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+PiANCj4+IEkndmUgcG9zdGVkIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1jYm9yLWRhdGUtdGFnLTAxLCB3aGljaCBpbmNsdWRl cyB0aGUgbnVtZXJpYyBkYXRlIHRhZyBwcm9wb3NlZCBieSBKw7ZyZy4gIEknbGwgcGxhbiB0byBq b2luIHRoZSBDQk9SIGNhbGwgdG9tb3Jyb3cgYW5kIHdvdWxkIGJlIGdsYWQgdG8gdGFsayBhYm91 dCB0aGlzIGRyYWZ0IGZvciBhIGZldyBtaW51dGVzLCBpZiB0aGVyZSdzIHJvb20gdG8gZG8gc28g aW4gdGhlIGFnZW5kYS4NCj4+IA0KPj4gCQkJCUJlc3Qgd2lzaGVzLA0KPj4gCQkJCS0tIE1pa2UN Cj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENCT1IgPGNib3It Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJpY2h0ZXIsIErDtnJnDQo+PiBTZW50OiBN b25kYXksIE1hcmNoIDE2LCAyMDIwIDEyOjMzIFBNDQo+PiBUbzogTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KPj4gQ2M6IGNib3JAaWV0Zi5vcmc7IENhcnN0ZW4gQm9y bWFubiA8Y2Fib0B0emkub3JnPjsgQW50aG9ueSBOYWRhbGluIA0KPj4gPHRvbnluYWRAbWljcm9z b2Z0LmNvbT4NCj4+IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtDYm9yXSBDQk9SIHRhZyBmb3Ig UkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVlcw0KPj4gDQo+Pj4gSsO2cmcgLSBJJ2xsIGFsc28gYWRk IHlvdSBhcyBhIGNvLWF1dGhvci4gIFdoYXQgYWZmaWxpYXRpb24gYW5kIGUtbWFpbCBhZGRyZXNz IGZvciB5b3Ugc2hvdWxkIEkgdXNlPyAgQW5kIGlzIHRoZXJlIGEgVVJMIGZvciBhIGJsb2cgb3Ig V2VicGFnZSB5b3UnZCBhbHNvIGxpa2UgbWUgdG8gaW5jbHVkZSBmb3IgeW91Pw0KPj4gDQo+PiBT b3JyeSwgSSBtaXNzZWQgdGhpcyBvbmUuDQo+PiANCj4+IFlvdSBjYW4gdXNlIGpvZXJnLnJpY2h0 ZXJAcGR2LWZzLmRlIChwZHYgRmluYW5jaWFsIFNvZnR3YXJlIEdtYkgpLiBJIGdvdCBubyBibG9n IG9yIHdlYnBhZ2UuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gLSBKw7ZyZw0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBWb246IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCj4+IEdlc2VuZGV0OiBNb250YWcsIDE2 LiBNw6RyeiAyMDIwIDE5OjUyOjM4DQo+PiBBbjogUmljaHRlciwgSsO2cmcNCj4+IENjOiBjYm9y QGlldGYub3JnOyBDYXJzdGVuIEJvcm1hbm47IEFudGhvbnkgTmFkYWxpbg0KPj4gQmV0cmVmZjog UmU6IFtDYm9yXSBDQk9SIHRhZyBmb3IgUkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVlcw0KPj4gDQo+ PiBKw7ZyZyAtIHBsZWFzZSByZXNwb25kIHRvIG15IHJlcXVlc3QgYmVsb3cgZm9yIGNvLWF1dGhv ciBpbmZvcm1hdGlvbi4NCj4+IA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhh bmtzLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4gDQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5K b25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQo+PiBTZW50OiBXZWRuZXNkYXks IE1hcmNoIDExLCAyMDIwIDM6MTEgUE0NCj4+IFRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHpp Lm9yZz47ICJSaWNodGVyLCBKw7ZyZyIgDQo+PiA8Sm9lcmcuUmljaHRlckBwZHYtRlMuLi5kZT4N Cj4+IENjOiBjYm9yQGlldGYub3JnOyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+OyBBbnRob255IA0KPj4gTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KPj4g U3ViamVjdDogUmU6IFtDYm9yXSBDQk9SIHRhZyBmb3IgUkZDIDMzMzkgZnVsbC1kYXRlIHZhbHVl cw0KPj4gDQo+PiBUaGUgcG9pbnQgb2YgaGF2aW5nIHRoZSB0YWcgaXMgdGhhdCB0aGUgY29kZSBr bm93cyB3aGF0IGZvbGxvd3MuICBJZiANCj4+IGEgcG9seW1vcnBoaWMgdGFnIHdlcmUgdXNlZCwg aW4gd2hpY2ggdHdvIHVucmVsYXRlZCByZXByZXNlbnRhdGlvbnMgDQo+PiBvZiBkYXRlcyBhcmUg bGVnYWwsIHRoZW4gdGhlIGNvZGUgZG9lc24ndCBrbm93IHdoYXQgZm9sbG93cy4gIEFuZCBpdCAN Cj4+IGFsc28gb3BlbnMgdXAgcXVlc3Rpb25zIHRoYXQgaXQgd291bGQgYmUgY2xlYW5lciB0byBu ZXZlciBoYXZlIHRvIA0KPj4gY29uc2lkZXIgLSBxdWVzdGlvbnMgc3VjaCBhcyAiSWYgdGhlIHBv bHltb3JwaGljIHRhZyBpcyBhZG9wdGVkLCBtdXN0IA0KPj4gTW9iaWxlIERyaXZlcidzIExpY2Vu c2VzIGFjY2VwdCBib3RoIHJlcHJlc2VudGF0aW9ucz8iICBBbmQgIldpbGwgDQo+PiBpbnRlcm9w ZXJhYmlsaXR5IGJlIGhhcm1lZCBpZiBzb21lIE1vYmlsZSBEcml2ZXIncyBMaWNlbnNlcyB1c2Ug b25lIA0KPj4gcmVwcmVzZW50YXRpb24gYW5kIHNvbWUgdXNlIHRoZSBvdGhlcj8iICAoVGhlIGFu c3dlciB0byB0aGF0IG9uZSBpcyANCj4+IHByb2JhYmx5ICJZZXMsIGludGVyb3BlcmFiaWxpdHkg d2lsbCBiZSBoYXJtZWQiLikNCj4+IA0KPj4gQ2Fyc3RlbiwgSSB0YWtlIHlvdXIgcG9pbnQgYWJv dXQgYm90aCBpbnRlZ2VycyBhbmQgZmxvYXRzIGJlaW5nIGFjY2VwdGFibGUgZm9yIHRhZyAxLiAg QnV0IHRob3NlIGFyZSBjbG9zZWx5IHJlbGF0ZWQgKG51bWVyaWMpIHJlcHJlc2VudGF0aW9ucyBv ZiB0aGUgc2FtZSB0aGluZy4gIFdoZXJlYXMgYSBkYXRlIHN0cmluZyB2ZXJzdXMgbnVtYmVyIG9m IGRheXMgcmVsYXRpdmUgdG8gdGhlIEVwb2NoIGFyZSBuZWFybHkgdW5yZWxhdGVkIHJlcHJlc2Vu dGF0aW9ucywgd2l0aCBmYWlybHkgY29tcGxpY2F0ZWQgY29udmVyc2lvbiBydWxlcyBiZXR3ZWVu IHRoZW0gKGludm9sdmluZyBsZWFwIHllYXJzLCBsZWFwIGNlbnR1cmllcywgbGVhcCA0MDB0aCB5 ZWFycywgZXRjLikuDQo+PiANCj4+IEdpdmVuIHRoYXQgSsO2cmcgc3RhdGVkIGJlbG93IHRoYXQg aGUncyBPSyB3aXRoIHVzaW5nIGRpZmZlcmVudCB0YWdzLCBJIHByb3Bvc2UgdGhhdCB3ZSBtb3Zl IGZvcndhcmQgd2l0aCB1c2luZyB0YWcgMTAwNCAocmVxdWVzdGVkKSBmb3IgUkZDIDMzMzkgZnVs bC1kYXRlIHZhbHVlcyBhbmQgdGFnIGNoYXIoJ2QnKSAocmVxdWVzdGVkKSBmb3IgaW50ZWdlciBu dW1iZXIgb2YgZGF5cyByZWxhdGl2ZSB0byB0aGUgRXBvY2guICBJZiBJIGRvbid0IGhlYXIgb2Jq ZWN0aW9ucyBzb29uLCBJJ2xsIHB1Ymxpc2ggdGhhdCBkcmFmdC4NCj4+IA0KPj4gSsO2cmcgLSBJ J2xsIGFsc28gYWRkIHlvdSBhcyBhIGNvLWF1dGhvci4gIFdoYXQgYWZmaWxpYXRpb24gYW5kIGUt bWFpbCBhZGRyZXNzIGZvciB5b3Ugc2hvdWxkIEkgdXNlPyAgQW5kIGlzIHRoZXJlIGEgVVJMIGZv ciBhIGJsb2cgb3IgV2VicGFnZSB5b3UnZCBhbHNvIGxpa2UgbWUgdG8gaW5jbHVkZSBmb3IgeW91 Pw0KPj4gDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTEsIDIw MjAgMjowOSBQTQ0KPj4gVG86ICJSaWNodGVyLCBKw7ZyZyIgPEpvZXJnLlJpY2h0ZXJAcGR2LUZT LmRlPg0KPj4gQ2M6IGNib3JAaWV0Zi5vcmc7IE1pa2UgSm9uZXMgDQo+PiA8TWljaGFlbC5Kb25l cz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyBBbnRob255IE5hZGFsaW4gDQo+PiA8 dG9ueW5hZEBtaWNyb3NvZnQuY29tPg0KPj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW0Nib3Jd IENCT1IgdGFnIGZvciBSRkMgMzMzOSBmdWxsLWRhdGUgdmFsdWVzDQo+PiANCj4+IE9uIDIwMjAt MDMtMTEsIGF0IDIxOjMxLCBSaWNodGVyLCBKw7ZyZyA8Sm9lcmcuUmljaHRlckBwZHYtRlMuZGU+ IHdyb3RlOg0KPj4+IA0KPj4+IChSZXBseWluZyB0byBtb3JlIHRoYW4gb25lIG1lc3NhZ2UgaGVy ZSkNCj4+PiANCj4+PiBDYXJzdGVuIEJvcm1hbm46DQo+Pj4+IElzIHRoYXQgYSBnb29kIHdheSBm b3J3YXJkPw0KPj4+IA0KPj4+IEkgYW0gZmluZSB3aXRoIHRoZSBzdWdnZXN0ZWQgcHJvY2VkdXJl Lg0KPj4gDQo+PiBHcmVhdCENCj4+IA0KPj4+IA0KPj4+PiBXaGF0IEkgbGlrZSBhYm91dCBNaWtl J3MgZHJhZnQgaXMgdGhhdCBoZSByZWZlcmVuY2VzIFJGQyAzMzM5LCANCj4+Pj4gd2hpY2ggYWxy ZWFkeSBpcyBhbiBlc3RhYmxpc2hlZCBzcGVjaWZpY2F0aW9uIGZvciBob3cgdG8gd3JpdGUgDQo+ Pj4+IGRhdGVzIHRleHR1YWxseQ0KPj4+IA0KPj4+IElTTyA4NjAxIGFsc28gZGVmaW5lcyB0aGlz IGZvcm1hdCBmb3IgZGF0ZXMuIEl0IGlzIG1lbnRpb25lZCBpbiB0aGUgIkRldGFpbGVkIFNlbWFu dGljcyINCj4+PiBzZWN0aW9uIG9mIG15IHByb3Bvc2FsLg0KPj4gDQo+PiBJU08gODYwMSBpcyB2 ZXJ5ICJmbGV4aWJsZSIuICBSRkMgMzMzOSB1c2VzIElTTyA4NjAxLCBidXQgaGVscHMgYnkgcmVz dHJpY3RpbmcgdGhpcyB0byBjb21tb25seSB1c2VkIGNhc2VzLg0KPj4gU28gSSB0aGluayByZWZl cmVuY2luZyBSRkMgMzMzOSBpcyBzdHJpY3RseSBiZXR0ZXIgdGhhbiBqdXN0IG5ha2VkIElTTyA4 NjAxLg0KPj4gDQo+Pj4gTWlrZSBKb25lczoNCj4+Pj4gSSdtIGZpbmUgbWVyZ2luZyBKw7ZyZydz IG51bWVyaWMgZGF0ZSB0YWcgaW50byBteSBkcmFmdCwgcHJvdmlkZWQgDQo+Pj4+IHRoYXQgdGhl IHJlc3VsdCBpcyBub3QgYSBwb2x5bW9ycGhpYyB0YWcsIGluIHdoaWNoIHRoZSB2YWx1ZSBjb3Vs ZCBiZSBlaXRoZXIgYSBudW1iZXIgb3IgYSBzdHJpbmcuDQo+Pj4+IFdlIHNob3VsZCBhbGxvY2F0 ZSBzZXBhcmF0ZSB0YWdzIGZvciBzdHJpbmcgZGF0ZSBhbmQgbnVtZXJpYyBkYXRlLCANCj4+Pj4g anVzdCBhcyB0YWdzDQo+Pj4+IDAgYW5kIDEgYXJlIGRpZmZlcmVudCwgYW5kIG5vdCBwb2x5bW9y cGhpYy4NCj4+PiANCj4+PiBJJ3ZlIGdvdCB0aGUgaW1wcmVzc2lvbiB0aGF0IHVzaW5nIGEgcG9s eW1vcnBoaWMgdGFnIHdvdWxkIGJlIG5vIG1ham9yIHByb2JsZW0uDQo+Pj4gV2UgY2FuIGV2ZW4g c3BlY2lmeSB0aGF0IGRlY29kZXJzIG1pZ2h0IG9ubHkgc3VwcG9ydCBvbmUgcmVwcmVzZW50YXRp b24gb2YgdGhlIHRhZy4NCj4+PiBJIHRoaW5rIGl0IHdvdWxkIGhhdmUgdGhlIHNhbWUgZWZmZWN0 IGlmIGEgZGVjb2RlciBzdXBwb3J0cyBvbmx5IG9uZSBvZiB0aGUgdHdvIHRhZ3MuDQo+Pj4gQnV0 IGVpdGhlciB3YXkgSSB3b3VsZCBoYXZlIG5vIG9iamVjdGlvbnMgdG8gdXNpbmcgdHdvIHRhZ3Mu DQo+PiANCj4+IEknbSBub3Qgc3VyZSBJIGxpa2UgdGhlIHRlcm0gInBvbHltb3JwaGljIiBoZXJl IHRvbyBtdWNoIC0gaW4gYW55IGNhc2UsIHRoZSAidmFsdWUiIHdvdWxkIGJlIGEgZGF0ZS4gIFRo ZSBjb250ZW50IGNvdWxkIGJlIGJvdGggdGV4dCBhbmQgbnVtYmVyLiAgVGFnIDEgYWxyZWFkeSBk b2VzIHRoaXMgKGludGVnZXIgdnMuIGZsb2F0aW5nLXBvaW50KSwgc28gd2UgYWxyZWFkeSBoYXZl IHRvIGRlYWwgd2l0aCB0aGVzZSAoaS5lLiwgYWxsb3cgYXBwbGljYXRpb25zIHRvIG5vdCBqdXN0 IHNheSAiVGFnIDEiLCBidXQgIlRhZyAxIHdpdGggaW50ZWdlciBjb250ZW50IikuICBCdXQgd2Ug ZGlkIHNlcGFyYXRlIFRhZyAwIGFuZCBUYWcgMSwgbW9zdGx5IGJlY2F1c2UgdGhlIHNlbWFudGlj cyBvZiB0aGUgdmFsdWUgYXJlIHN1YnRseSBkaWZmZXJlbnQuICBBcmUgdGhleSBoZXJlPw0KPj4g DQo+Pj4gTGF1cmVuY2UgTHVuZGJsYWRlOg0KPj4+PiBJJ2Qgc3VnZ2VzdCB0aGUgbnVtZXJpYyBk YXRlIGJlIHJlc3RyaWN0ZWQgdG8gaW50ZWdlcnMuIE5vIGZsb2F0cywgDQo+Pj4+IGJpZ251bXMs IGRlY2ltYWwgZnJhY3Rpb25zLg0KPj4+IA0KPj4+IFllcywgdGhhdCB3YXMgdGhlIHBsYW4uIE9u bHkgbWFqb3IgdHlwZXMgMCBhbmQgMS4NCj4+IA0KPj4gRmluZXIgZ3JhbnVsYXJpdHkgYmV0d2Vl biBkYXRlcyB3b3VsZCBiZSB0aW1lcywgd2hpY2ggd2UgYWxyZWFkeSBoYXZlLCBzbyB0aGlzIG5h dHVyYWxseSBzaG91bGQgYmUgaW50ZWdlcnMuDQo+PiANCj4+Pj4gRnJhY3Rpb25zIG9mIGRheXMg Y2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRhZyAwIG9yIHRhZyAxIHVzaW5nIGhvdXJzLCANCj4+Pj4g bWludXRlcywgc2Vjb25kcy4gNjQtYml0IGludGVnZXIgY291bnRzIG9mIGRheXMgYXJlIGxhcmdl IGVub3VnaC4NCj4+PiANCj4+PiBUaGlzIEkgZG9uJ3QgdW5kZXJzdGFuZC4gVGhlIHByb3Bvc2Fs IG9ubHkgaGFuZGxlcyB3aG9sZSBkYXlzIGFzIG9uZSBudW1iZXIuDQo+PiANCj4+IFJpZ2h0LiAg T25seSBmdWxsIGRheXMuICAoVGhlIHJlbGF0ZWQgb2JzZXJ2YXRpb24gaXMgdGhhdCB0aGVzZSBh cmUgDQo+PiBhbHdheXMgaW4gdGhlIGxvY2FsIHRpbWUgb2Ygc29tZSBjb250ZXh0IHRoYXQgaXMg bm90IGV4cHJlc3NlZCwgd2hpY2ggDQo+PiBpcyByYXRoZXIgZGlmZmVyZW50IGZyb20gb3VyIHRp bWUgdGFncy4pDQo+PiANCj4+PiBBbm90aGVyIHRoaW5nIHRvIGNvbnNpZGVyOg0KPj4+IFdlIHNo b3VsZCBtZW50aW9uIHRoYXQgdGhpcyB0YWcocykgdXNlIHRoZSBwcm9sZXB0aWMgR3JlZ29yaWFu IA0KPj4+IGNhbGVuZGFyLiBTbyB0aGF0IGRhdGVzIGJlZm9yZSB0aGUgR3JlZ29yaWFuIGNhbGVu ZGFyIGhhdmUgYSB1bmlxdWUgc2VtYW50aWNzLg0KPj4gDQo+PiBHb29kIHBvaW50LiAgSW4gNzA0 OWJpcywgd2UganVzdCBzYXk6DQo+PiANCj4+IE5lZ2F0aXZlIHZhbHVlcyAobWFqb3IgdHlwZSAx IGFuZCBuZWdhdGl2ZSBmbG9hdGluZy1wb2ludCBudW1iZXJzKSANCj4+IGFyZSBpbnRlcnByZXRl ZCBhcyBkZXRlcm1pbmVkIGJ5IHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgYXMgDQo+PiB0 aGVyZSBpcyBubyB1bml2ZXJzYWwgc3RhbmRhcmQgZm9yIFVUQyBjb3VudC1vZi1zZWNvbmRzIHRp bWUgYmVmb3JlIA0KPj4gMTk3MC0wMS0wMVQwMDowMFogKHRoaXMgaXMgcGFydGljdWxhcmx5IHRy dWUgZm9yIHBvaW50cyBpbiB0aW1lIHRoYXQgDQo+PiBwcmVjZWRlIGRpc2NvbnRpbnVpdGllcyBp biBuYXRpb25hbCBjYWxlbmRhcnMpLiAgWy5dDQo+PiANCj4+IFRoYXQgaXMgbGVzcyBvZiBhIHBy b2JsZW0gb24gdGhlIGRhdGUtb25seSBzaWRlIChhcyBsb25nIGFzIGRhdGVzIGNoYW5nZSBvbiBs b2NhbCBtaWRuaWdodC4gYW5kIG5vdCBub29uKSwgc28gd2UgbWF5IGJlIGFibGUgdG8gYmUgbW9y ZSBzcGVjaWZpYy4NCj4+IA0KPj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ0JPUiBtYWlsaW5nIGxp c3QNCj4+IENCT1JAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2Jvcg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gQ0JPUiBtYWlsaW5nIGxpc3QNCj4+IENCT1JAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0KPj4gDQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ0JPUiBtYWlsaW5n IGxpc3QNCj4+IENCT1JAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2Jvcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gQ0JPUiBtYWlsaW5nIGxpc3QNCj4gQ0JPUkBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0K From nobody Wed Jun 3 09:09:58 2020 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 B91E03A0755 for ; Wed, 3 Jun 2020 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_LzzBLBZUqj for ; Wed, 3 Jun 2020 09:09:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B673A0743 for ; Wed, 3 Jun 2020 09:09:51 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49cYlL13ZMzygQ; Wed, 3 Jun 2020 18:09:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann Date: Wed, 3 Jun 2020 18:09:49 +0200 X-Mao-Original-Outgoing-Id: 612893389.715145-9582dc672f2f042477f3a17dde8e78c6 Content-Transfer-Encoding: quoted-printable Message-Id: <71EA3B9B-D8EE-47B2-95AC-98F05D33986E@tzi.org> References: <20200504203532.19BAA81B33@carsa.obspm.fr> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] MJD (Fwd: Bulletin B number 387) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:09:57 -0000 Today, we had a brief discussion about MJD, modified Julian dates. Just as a random example of the use of MJD in the fundamental gears that = keep our timekeeping going: The International Earth Rotation Service (IERS) sends out bulletins = regularly that explain how the earth moves and what that means for Sun = position based timekeeping (UT1) vs. atomic time keeping (TAI). This is needed for any astronomy that tries to use TAI-based time = sources (e.g., GPS), as well as for the decision when to insert leap = seconds (which is based on IERS data). They give this information for each date so you can retroactively adjust = what you saw in your telescope. The dates are given in Gregorian form, e.g., 2020-04-01, but also (more = usefully for astronomers) in MJD, here 58940. Now if you know that = (Time.parse("2020-04-01T00:00:00+00:00").utc-Time.parse('1970-01-01T00:00:= 00+00:00').utc)/86400.0 =3D> 18353.0, you can add that to the MJD of = 40587 for the UNIX epoch, and unsurprisingly you get: 58940. Oh, and = today it=E2=80=99s 59003 (Date.today.mjd). I=E2=80=99m still looking for a citable reference from 1957, when = Smithsonian Astrophysical Observatory (SAO) invented MJD by subtracting = 2400000.5 from JD (introduced by Joseph Scaliger in the 16th century = based on January 1, 4713 B.C.) to be able to track Sputnik efficiently = on a 36-bit IBM 704 computer (using 18 bits for the date and the other = 18 bits for the time of day). We may want to pick this subject up again when discussing 63-bit = absolute time with 100 ns granularity :-) or some such... Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: iers.eoppc@obspm.fr (IERS EOP Product Center) > Subject: Bulletin B number 387 > Date: 2020-05-04 at 22:35:31 CEST > To: bulb.iers@obspm.fr > Reply-To: iers.eoppc@obspm.fr (IERS EOP Product Center) >=20 > = BULLETIN B 387 > 4 May = 2020 =20 >=20 > Contents are described in = ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.pdf=20 > =09 > 1 - DAILY FINAL VALUES OF x, y, UT1-UTC, dX, dY > Angular unit is milliarcsecond (mas), time unit is millisecond (ms).=20= > Upgraded solution from March 1 2017 - consistent with ITRF 2014. >=20 > DATE MJD x y UT1-UTC dX dY x = err y err UT1 err dX err dY err > (0 h UTC) mas mas ms mas mas = mas mas ms mas mas >=20 > Final values=20 >=20 > Mean formal error 0.053 0.038 0.0065 0.025 0.055=20 >=20 > 2020 3 2 58910 27.052 357.171 -205.5930 0.061 -0.015 = 0.056 0.039 0.0095 0.070 0.088 > 2020 3 3 58911 26.374 359.002 -206.1635 0.090 -0.029 = 0.056 0.039 0.0094 0.071 0.089 > 2020 3 4 58912 26.040 360.668 -206.6763 0.090 -0.006 = 0.056 0.039 0.0093 0.071 0.088 > 2020 3 5 58913 26.271 362.020 -207.1658 0.083 0.026 = 0.056 0.039 0.0092 0.072 0.087 > 2020 3 6 58914 26.971 363.910 -207.6964 0.075 0.058 = 0.056 0.039 0.0089 0.070 0.083 > 2020 3 7 58915 27.743 365.695 -208.3559 0.049 0.050 = 0.056 0.039 0.0087 0.071 0.081 > 2020 3 8 58916 28.156 367.442 -209.2279 0.016 0.026 = 0.056 0.038 0.0081 0.066 0.075 > 2020 3 9 58917 28.068 369.116 -210.3544 -0.017 0.003 = 0.055 0.038 0.0077 0.067 0.073 > 2020 3 10 58918 28.186 370.679 -211.7167 -0.050 -0.020 = 0.055 0.039 0.0075 0.067 0.071 > 2020 3 11 58919 28.655 372.325 -213.2290 -0.012 0.001 = 0.055 0.039 0.0073 0.067 0.068 > 2020 3 12 58920 29.168 373.782 -214.7503 0.045 0.034 = 0.055 0.039 0.0071 0.067 0.065 > 2020 3 13 58921 30.390 375.474 -216.1386 0.102 0.067 = 0.054 0.039 0.0069 0.067 0.063 > 2020 3 14 58922 31.837 377.519 -217.2921 0.092 0.111 = 0.054 0.039 0.0067 0.064 0.057 > 2020 3 15 58923 33.166 379.483 -218.1787 0.059 0.160 = 0.053 0.038 0.0062 0.059 0.053 > 2020 3 16 58924 34.196 380.925 -218.8244 0.026 0.209 = 0.053 0.038 0.0060 0.059 0.050 > 2020 3 17 58925 34.810 382.174 -219.2893 -0.007 0.257 = 0.052 0.038 0.0057 0.058 0.048 > 2020 3 18 58926 35.518 383.028 -219.6482 -0.015 0.152 = 0.052 0.038 0.0056 0.057 0.045 > 2020 3 19 58927 36.746 383.993 -219.9551 -0.016 0.005 = 0.052 0.038 0.0054 0.057 0.043 > 2020 3 20 58928 38.706 385.063 -220.2542 -0.017 -0.143 = 0.051 0.038 0.0053 0.057 0.041 > 2020 3 21 58929 40.911 386.045 -220.5675 -0.013 -0.159 = 0.051 0.038 0.0052 0.057 0.040 > 2020 3 22 58930 42.767 387.279 -220.9353 -0.008 -0.127 = 0.051 0.038 0.0051 0.057 0.038 > 2020 3 23 58931 43.796 388.552 -221.3969 -0.002 -0.096 = 0.050 0.038 0.0049 0.057 0.037 > 2020 3 24 58932 44.596 389.940 -221.9350 0.004 -0.064 = 0.050 0.038 0.0048 0.056 0.035 > 2020 3 25 58933 44.822 391.441 -222.4998 -0.025 -0.023 = 0.050 0.038 0.0048 0.056 0.036 > 2020 3 26 58934 44.447 393.068 -223.0586 -0.062 0.021 = 0.050 0.038 0.0049 0.057 0.037 > 2020 3 27 58935 43.820 394.134 -223.5768 -0.099 0.065 = 0.051 0.038 0.0050 0.057 0.037 > 2020 3 28 58936 44.678 395.036 -224.0270 -0.091 0.067 = 0.051 0.038 0.0051 0.057 0.038 > 2020 3 29 58937 45.811 396.474 -224.3985 -0.065 0.053 = 0.051 0.038 0.0052 0.058 0.038 > 2020 3 30 58938 47.066 397.981 -224.6996 -0.039 0.038 = 0.051 0.038 0.0052 0.058 0.039 > 2020 3 31 58939 48.786 399.658 -224.9459 -0.013 0.024 = 0.052 0.038 0.0053 0.059 0.039 > 2020 4 1 58940 50.873 401.240 -225.1677 -0.019 -0.007 = 0.052 0.038 0.0054 0.060 0.040 >=20 > Preliminary extension=20 > 2020 4 2 58941 52.629 403.274 -225.4275 -0.033 -0.043 = 0.053 0.038 0.0056 0.060 0.041 > 2020 4 3 58942 54.045 405.201 -225.8108 -0.047 -0.080 = 0.053 0.039 0.0057 0.061 0.042 > 2020 4 4 58943 54.939 406.879 -226.4131 -0.042 -0.057 = 0.054 0.039 0.0059 0.062 0.043 > 2020 4 5 58944 55.448 407.948 -227.3108 -0.030 -0.013 = 0.054 0.039 0.0060 0.062 0.044 > 2020 4 6 58945 55.942 408.915 -228.5296 -0.018 0.032 = 0.055 0.039 0.0061 0.063 0.045 > 2020 4 7 58946 56.202 409.418 -230.0133 -0.005 0.076 = 0.055 0.039 0.0063 0.064 0.046 > 2020 4 8 58947 56.867 409.951 -231.6181 0.038 0.012 = 0.055 0.040 0.0064 0.064 0.046 > 2020 4 9 58948 57.726 410.982 -233.1940 0.089 -0.080 = 0.056 0.040 0.0065 0.065 0.046 > 2020 4 10 58949 58.113 412.055 -234.6309 0.079 -0.071 = 0.056 0.040 0.0067 0.066 0.047 > 2020 4 11 58950 58.566 412.943 -235.7588 0.046 -0.024 = 0.057 0.040 0.0068 0.067 0.049 > 2020 4 12 58951 59.057 414.030 -236.6098 0.013 0.022 = 0.057 0.041 0.0069 0.068 0.050 > 2020 4 13 58952 59.805 415.374 -237.2074 -0.019 0.069 = 0.058 0.042 0.0070 0.069 0.052 > 2020 4 14 58953 60.918 416.776 -237.5996 -0.052 0.116 = 0.059 0.042 0.0071 0.070 0.053 > 2020 4 15 58954 62.146 418.046 -237.8591 -0.085 0.163 = 0.060 0.043 0.0072 0.071 0.055 > 2020 4 16 58955 62.853 419.714 -238.0355 0.036 0.069 = 0.062 0.045 0.0075 0.072 0.058 > 2020 4 17 58956 63.924 421.358 -238.2368 0.199 -0.062 = 0.064 0.046 0.0078 0.073 0.062 > 2020 4 18 58957 64.490 423.077 -238.5501 0.000 0.000 = 0.066 0.048 0.0081 0.075 0.067 > 2020 4 19 58958 64.316 424.255 -239.0153 2.224 1.502 = 0.047 0.031 0.0079 0.041 0.039 > 2020 4 20 58959 63.747 425.151 -239.4957 3.387 2.493 = 0.048 0.032 0.0082 0.042 0.042 > 2020 4 21 58960 63.142 425.931 -239.9896 4.549 3.484 = 0.049 0.033 0.0085 0.043 0.045 > 2020 4 22 58961 63.226 426.511 -240.4778 1.970 1.158 = 0.050 0.033 0.0088 0.500 0.500 > 2020 4 23 58962 64.174 427.385 -240.9283 1.327 0.785 = 0.050 0.034 0.0091 0.500 0.500 > 2020 4 24 58963 65.452 428.308 -241.3520 0.757 0.463 = 0.051 0.034 0.0094 0.500 0.500 > 2020 4 25 58964 67.020 429.350 -241.6901 0.487 0.318 = 0.052 0.035 0.0097 0.500 0.500 > 2020 4 26 58965 68.387 430.786 -241.8633 0.536 0.347 = 0.053 0.035 0.0100 0.500 0.500 > 2020 4 27 58966 69.326 432.013 -241.9663 0.738 0.445 = 0.054 0.036 0.0103 0.500 0.500 > 2020 4 28 58967 70.543 432.912 -242.0334 0.882 0.492 = 0.055 0.037 0.0107 0.500 0.500 > 2020 4 29 58968 72.198 433.759 -242.1119 0.858 0.442 = 0.056 0.037 0.0111 0.500 0.500 > 2020 4 30 58969 74.118 434.658 -242.2219 0.714 0.341 = 0.057 0.038 0.0115 0.500 0.500 > 2020 5 1 58970 75.783 435.916 -242.4483 0.586 0.275 = 0.058 0.039 0.0119 0.500 0.500 >=20 > =09 > 2 - DAILY FINAL VALUES OF CELESTIAL POLE OFFSETS dPsi1980 & dEps1980 > dPsi1980 dEps1980 ....dPsi,dEps / IAU 1980 precession-nutation = model =20 > Description : ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.pdf > The Reference Systems are described in the 2006 IERS Annual Report. >=20 > DATE MJD dPsi1980 dEps1980 sig dPsi sig dEps =20 > (0 h UTC) mas mas mas mas =20 >=20 > 2020 3 2 58910 -107.618 -8.141 0.176 0.088 > 2020 3 3 58911 -107.667 -8.239 0.178 0.089 > 2020 3 4 58912 -107.675 -8.191 0.178 0.088 > 2020 3 5 58913 -107.792 -8.157 0.181 0.087 > 2020 3 6 58914 -108.125 -8.377 0.176 0.083 > 2020 3 7 58915 -108.350 -8.872 0.178 0.081 > 2020 3 8 58916 -107.965 -9.254 0.166 0.075 > 2020 3 9 58917 -107.107 -9.201 0.168 0.073 > 2020 3 10 58918 -106.499 -8.856 0.168 0.071 > 2020 3 11 58919 -106.433 -8.568 0.168 0.068 > 2020 3 12 58920 -106.813 -8.530 0.168 0.065 > 2020 3 13 58921 -107.160 -8.597 0.168 0.063 > 2020 3 14 58922 -107.352 -8.624 0.161 0.057 > 2020 3 15 58923 -107.339 -8.667 0.148 0.053 > 2020 3 16 58924 -107.299 -8.785 0.148 0.050 > 2020 3 17 58925 -107.403 -8.896 0.146 0.048 > 2020 3 18 58926 -107.525 -9.057 0.143 0.045 > 2020 3 19 58927 -107.478 -9.188 0.143 0.043 > 2020 3 20 58928 -107.167 -9.328 0.143 0.041 > 2020 3 21 58929 -106.746 -9.328 0.143 0.040 > 2020 3 22 58930 -106.488 -9.174 0.143 0.038 > 2020 3 23 58931 -106.488 -8.903 0.143 0.037 > 2020 3 24 58932 -106.628 -8.656 0.141 0.035 > 2020 3 25 58933 -106.814 -8.589 0.141 0.036 > 2020 3 26 58934 -106.872 -8.706 0.143 0.037 > 2020 3 27 58935 -106.797 -8.875 0.143 0.037 > 2020 3 28 58936 -106.602 -9.048 0.143 0.038 > 2020 3 29 58937 -106.510 -9.240 0.146 0.038 > 2020 3 30 58938 -106.577 -9.482 0.146 0.039 > 2020 3 31 58939 -106.605 -9.694 0.148 0.039 > 2020 4 1 58940 -106.503 -9.774 0.151 0.040 >=20 >=20 > 3 - EARTH ANGULAR VELOCITY : DAILY FINAL VALUES OF LOD, OMEGA AT 0hUTC >=20 > LOD : Excess of the Length of day - 86400 s TAI=20 > OMEGA : Earth angular velocity =20 > Description: ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.pdf >=20 > DATE MJD LOD sigma OMEGA sigma =20= > (0 h UTC) ms ms mas/ms mas/ms >=20 > 2020 3 2 58910 0.5935 0.0123 15.04106707535 0.00000000214=20= > 2020 3 3 58911 0.5165 0.0124 15.04106708875 0.00000000216=20= > 2020 3 4 58912 0.4635 0.0124 15.04106709798 0.00000000216=20= > 2020 3 5 58913 0.5028 0.0125 15.04106709114 0.00000000218=20= > 2020 3 6 58914 0.6226 0.0126 15.04106707028 0.00000000219=20= > 2020 3 7 58915 0.8000 0.0123 15.04106703940 0.00000000214=20= > 2020 3 8 58916 0.9841 0.0124 15.04106700735 0.00000000216=20= > 2020 3 9 58917 1.2166 0.0124 15.04106696688 0.00000000216=20= > 2020 3 10 58918 1.4868 0.0125 15.04106691984 0.00000000218=20= > 2020 3 11 58919 1.5777 0.0126 15.04106690401 0.00000000219=20= > 2020 3 12 58920 1.4394 0.0126 15.04106692809 0.00000000219=20= > 2020 3 13 58921 1.2287 0.0127 15.04106696477 0.00000000221=20= > 2020 3 14 58922 0.9841 0.0128 15.04106700735 0.00000000223=20= > 2020 3 15 58923 0.7350 0.0125 15.04106705072 0.00000000218=20= > 2020 3 16 58924 0.5614 0.0125 15.04106708094 0.00000000218=20= > 2020 3 17 58925 0.4298 0.0126 15.04106710385 0.00000000219=20= > 2020 3 18 58926 0.3245 0.0126 15.04106712218 0.00000000219=20= > 2020 3 19 58927 0.2934 0.0127 15.04106712759 0.00000000221=20= > 2020 3 20 58928 0.3209 0.0127 15.04106712281 0.00000000221=20= > 2020 3 21 58929 0.3708 0.0128 15.04106711412 0.00000000223=20= > 2020 3 22 58930 0.4059 0.0125 15.04106710801 0.00000000218=20= > 2020 3 23 58931 0.4873 0.0126 15.04106709384 0.00000000219=20= > 2020 3 24 58932 0.5568 0.0126 15.04106708174 0.00000000219=20= > 2020 3 25 58933 0.5687 0.0127 15.04106707967 0.00000000221=20= > 2020 3 26 58934 0.5606 0.0127 15.04106708108 0.00000000221=20= > 2020 3 27 58935 0.4715 0.0127 15.04106709659 0.00000000221=20= > 2020 3 28 58936 0.4307 0.0128 15.04106710369 0.00000000223=20= > 2020 3 29 58937 0.3247 0.0128 15.04106712214 0.00000000223=20= > 2020 3 30 58938 0.2583 0.0129 15.04106713370 0.00000000225=20= > 2020 3 31 58939 0.2069 0.0129 15.04106714265 0.00000000225=20= > 2020 4 1 58940 0.2524 0.0130 15.04106713473 0.00000000226=20= >=20 >=20 > 4 - INFORMATION ON TIME SCALES=20 >=20 >=20 > TAI - UTC =3D 37 s. during period [58910-58940] >=20 > No leap second introduced during period [58910-58940] >=20 > All information concerning time scales :=20 > - leap seconds announcements : Bulletin C=20 > - DUT1 announcements (UT1-UTC with 0.1 s accuracy) : Bulletin D > can be found at :=20 > - web site : http://hpiers.obspm.fr/eop-pc/ > - anonymous ftp://hpiers.obspm.fr/iers/=20 >=20 >=20 > 5 - SUMMARY OF CONTRIBUTED EARTH ORIENTATION PARAMETERS SERIES > This section gives the average precision of the individual series, = some of them > contributing to the combination (*) and their average agreement with = it.=20 > The period covered is that one of Bulletin B.=20 >=20 > Units : micro-arc-seconds for x/y/dX/dY micro-seconds for = UT1/LOD > = --------------------------------------------------------------------------= --- > EOP series first line : Mean formal uncertainty > Periods covered second line : Weighted RMS agreement with = Bulletin B > = --------------------------------------------------------------------------= --- > x y UT1 LOD dX dY Data = Number =09 >=20 > VLBI Standards >=20 > BKG =20 > bkg00014.eops 62 71 3 - 14 36 4 > 58914.27 to 58935.27 109 106 4 - 40 50 >=20 > GSFC =20 > gsf2019d.eoxy 37 36 2 5 11 28 9 > 58911.21 to 58939.21 79 47 4 16 50 67 >=20 > IAA =20 > iaa2007a.eops 38 43 2 - 11 30 9 > 58911.21 to 58939.21 203 189 10 - 68 85 >=20 > USNO =20 > usn2020a.eoxy 31 32 1 - 12 33 9 > 58911.21 to 58939.21 96 48 4 - 60 81 >=20 > IVS * > ivs14r1X.eops 30 25 1 - 7 20 9 > 58911.20 to 58939.22 43 46 2 - 4 9 >=20 >=20 > VLBI Intensive >=20 > GSI * > gsiint2c.eopi - - 8 - - - 7 > 58915.33 to 58937.33 - - 30 - - - >=20 > BKG * > bkgint14.eopi - - 15 - - - 29 > 58910.79 to 58939.79 - - 25 - - - >=20 > GSFC * > gsf2019d.eopi - - 13 - - - 38 > 58910.31 to 58939.79 - - 38 - - - >=20 > IAA * > iaa2019a.eopi - - 13 - - - 38 > 58910.31 to 58939.79 - - 32 - - - >=20 > USNO * > usnouint.data - - 14 - - - 33 > 58910.31 to 58939.79 - - 35 - - - >=20 >=20 > GPS >=20 > CODE =20 > COD*ERP_R 5 5 - 1 - - 30 > 58910.50 to 58939.50 51 31 - 10 - - >=20 > JPL =20 > jpl*.erp 9 10 - 8 - - 30 > 58910.50 to 58939.50 60 39 - 17 - - >=20 > GFZ =20 > gfz*.erp 4 4 - 1 - - 30 > 58910.50 to 58939.50 54 43 - 13 - - >=20 > ESOC =20 > esa*.erp 7 9 - 4 - - 30 > 58910.50 to 58939.50 52 32 - 11 - - >=20 > SIO =20 > sio*.erp siu*.erp 38 47 - 17 - - 30 > 58910.50 to 58939.50 62 49 - 19 - - >=20 > EMR =20 > emr*.erp 3 3 - 1 - - 30 > 58910.50 to 58939.50 55 49 - 13 - - >=20 > IAA =20 > gnss.res 0 0 - 0 - - 30 > 58910.50 to 58939.50 66 63 - 30 - - >=20 > GRGS =20 > grg*.erp 58 58 - 0 - - 24 > 58916.50 to 58939.50 57 35 - 9 - - >=20 > ASI =20 > asi*.erp 9 9 - 0 - - 29 > 58910.50 to 58939.50 97 43 - 36 - - >=20 > MIT =20 > mit*.erp 12 12 - 1 - - 30 > 58910.50 to 58939.50 58 37 - 16 - - >=20 > IGR * > igs96p02.erp 14 13 - 2 - - 30 > 58910.50 to 58939.50 46 32 - 13 - - >=20 > IGS * > igs00p03.erp 3 3 - 0 - - 30 > 58910.50 to 58939.50 55 34 - 14 - - >=20 >=20 > SLR >=20 > MCC =20 > tg*.02 173 234 - 29 - - 20 > 58910.00 to 58929.00 97 161 - 124 - - >=20 > IAA =20 > slr_v.dat 67 91 - 5 - - 28 > 58910.00 to 58940.00 293 289 - 37 - - >=20 > ASI =20 > slr_oca*.eop 66 97 - 20 - - 30 > 58910.50 to 58939.50 160 281 - 67 - - >=20 > ILRS * > ilrsa.eop 43 59 - 8 - - 30 > 58910.50 to 58939.50 214 265 - 24 - - >=20 >=20 > BULLETIN A >=20 > NEOS =20 > mark3.out 31 27 4 - - - 31 > 58910.00 to 58940.00 71 36 18 - - - >=20 > To unsubscribe : = http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletin_registration.htm= l From nobody Wed Jun 3 09:17:56 2020 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 5876A3A07A8 for ; Wed, 3 Jun 2020 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJZZvb7u8fcy for ; Wed, 3 Jun 2020 09:17:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F5F3A07A3 for ; Wed, 3 Jun 2020 09:17:52 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49cYwZ4S1dzysX; Wed, 3 Jun 2020 18:17:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 3 Jun 2020 18:17:50 +0200 Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 612893870.2209229-ab26f9da62a9605bde3c689dc0cdd472 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC190D2-F87C-4B02-A173-BD5A080123F5@tzi.org> References: To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:17:54 -0000 On 2020-06-03, at 17:02, Mike Jones = wrote: >=20 > Let's discuss whether to add a non-normative reference to the Modified = Julian Date to the draft or not. I would phrase that as an implementation note, and it will be = immediately useful for implementers that have acquired some knowledge = about dates and times. It is also useful as a way for readers of the = document to disambiguate any questions they might have about the value = in the tag content. (We might also include an example, e.g., for today, 2020-05-03: >> Date.today.mjd-40587 Calculation based on current MJD =3D> 18416 >> Time.now.to_i/86400 Calculation based on seconds since UNIX = epoch =3D> 18416 ). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 3 11:38:04 2020 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 DA2653A0DDF for ; Wed, 3 Jun 2020 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n-brYr28bgA for ; Wed, 3 Jun 2020 11:38:01 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C615D3A0DDC for ; Wed, 3 Jun 2020 11:38:01 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id gYH2jJUUU4pcAgYH3jierC; Wed, 03 Jun 2020 11:38:01 -0700 X-CMAE-Analysis: v=2.3 cv=aMSOVo1m c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=oGbIuagOAAAA:20 a=48vgC7mUAAAA:8 a=2Tv5k7bOPORSV1WS_zwA:9 a=QEXdDO2ut3YA:10 a=rKrVYePj7rwA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> Date: Wed, 3 Jun 2020 11:38:00 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9996BD7E-1E2C-4CAA-AC8D-3261DF4EC74B@island-resort.com> References: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfDnYCeh34T/BGtI81Hok2xuwbSWJQMKOBfXmUpcghVDtqmo9fxK2uCRmQO2Gi6MhnauN5U7K0S8zi4ti6MJPG5GAQ5dxwE5vGVLh+e7ozN/kBrEa2arT qpSqIHH0AK2SwUUNHNDwsdz2LpHYjli6KpM5WXxqlQvwaIe99fGqrKkuyPnbdbJ2HMubU0EFO6gJ5A== Archived-At: Subject: Re: [Cbor] [cbor-wg/CBORbis] Section 7.1 and IANA considerations. (#196) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 18:38:03 -0000 Was thinking the space for specification required was too small myself = the other day. Looks like no conflict with existing registrations. So = yes. LL=20 > On Jun 3, 2020, at 7:25 AM, Carsten Bormann wrote: >=20 > I just submitted a pull request that addresses some comments on = Section 7.1, extension points. > I used the occasion to pick up the idea to move the lower half of the = 1+2 tag space (256 to 32767) to specification required. >=20 > Comments on this? >=20 >> You can view, comment on, or merge this pull request online at: >>=20 >> https://github.com/cbor-wg/CBORbis/pull/196 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jun 3 11:38:50 2020 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 416933A0DE0 for ; Wed, 3 Jun 2020 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ0LS2krnQaR for ; Wed, 3 Jun 2020 11:38:47 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AEB3A0DDC for ; Wed, 3 Jun 2020 11:38:47 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id gYH2jJUUU4pcAgYHmjieu3; Wed, 03 Jun 2020 11:38:46 -0700 X-CMAE-Analysis: v=2.3 cv=aMSOVo1m c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=gKmFwSsBAAAA:8 a=oGbIuagOAAAA:20 a=48vgC7mUAAAA:8 a=6L8xPJO7MgkfgLVIb9EA:9 a=QEXdDO2ut3YA:10 a=tGkhvlCg9oqejYYN2zAA:9 a=5aZIJ-AgiEC5Xipm:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <0A92DA3F-5F5A-4007-91B1-783FD4AA10B2@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_70D53CA2-5F85-45E2-9E5C-2A6BE05B7F85" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 3 Jun 2020 11:38:46 -0700 In-Reply-To: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfMT6yNB8bnmODjL2Be4cZjIwTQB6ESgcso5GfbJNtnayS1Fq32W0pV3g0Q9vyFlBGMqww4NyVjO3Vz4x3dDYOybdqpGSlbwR+xA9KjOSWA+NDyDdRIyZ 7V/hQMB4LKYsBd60PnjNMLZ96r6IV3ttTG7pIHrRgaH0wENClc33QxCywP3IKcIKJRQHqljUrn9WCQ== Archived-At: Subject: [Cbor] proprietary tags (was Re: [cbor-wg/CBORbis] Section 7.1 and IANA considerations. (#196)) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 18:38:49 -0000 --Apple-Mail=_70D53CA2-5F85-45E2-9E5C-2A6BE05B7F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There seems to be no provision for a proprietary tag with no public = description. First come first served still requires Semantics (short = form). Maybe Acme can just say =E2=80=9CAcme proprietary tag=E2=80=9D = for the Semantics if Acme wants to register without giving any details? LL > On Jun 3, 2020, at 7:25 AM, Carsten Bormann wrote: >=20 > I just submitted a pull request that addresses some comments on = Section 7.1, extension points. > I used the occasion to pick up the idea to move the lower half of the = 1+2 tag space (256 to 32767) to specification required. >=20 > Comments on this? >=20 >> You can view, comment on, or merge this pull request online at: >>=20 >> https://github.com/cbor-wg/CBORbis/pull/196 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_70D53CA2-5F85-45E2-9E5C-2A6BE05B7F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
There seems to be no provision for a proprietary tag with no = public description. First come first served still requires Semantics (short form). Maybe Acme can just = say =E2=80=9CAcme proprietary tag=E2=80=9D for the Semantics if = Acme wants to register without giving any details?

LL


On Jun 3, 2020, at 7:25 AM, = Carsten Bormann <cabo@tzi.org> wrote:

I = just submitted a pull request that addresses some comments on Section = 7.1, extension points.
I used the occasion to pick up the = idea to move the lower half of the 1+2 tag space (256 to 32767) to = specification required.

Comments on = this?

You can view, comment on, or merge this pull request online = at:

 https://github.com/cbor-wg/CBORbis/pull/196

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


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

= --Apple-Mail=_70D53CA2-5F85-45E2-9E5C-2A6BE05B7F85-- From nobody Wed Jun 3 11:42:17 2020 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 75BD93A0E04 for ; Wed, 3 Jun 2020 11:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 VlvrrXc3i0W0 for ; Wed, 3 Jun 2020 11:42:14 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 F16243A0E03 for ; Wed, 3 Jun 2020 11:42:13 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id r9so1199794ual.1 for ; Wed, 03 Jun 2020 11:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KAtwymRIMbal15DweHeCv36AQRlpngAkd+79lfrmXN8=; b=kP8q6chAXYOyaDdKI53ucDn7msO5POSQEOkL4AbpJYXQqPZaDyh9TNK7kfAOpYBlS6 zkZPCq+KvS2nZ8QFiF5NgKJP4av54I4hg+7uI8efBwssqRN4RUUdc7L/K9niYO46pqk+ 031ICbLYZhINsVHLdmwCKLe8NhY0bQGKv4GtKwTBuc93OctYEUN3AYD06gTxZOFL6yYt ANDLWWenJZgpAfHnBSjovFWkl/wOFDCCo6tDVDbiuOsRsyGl/XzcpNS6PMzCq4MLgHut lzijITRbDiLoZa8EPpP0cGwLs0GONhl60c39M/kzfo2qkYEvvrms2m1RiW3RokYcSo5M iJWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KAtwymRIMbal15DweHeCv36AQRlpngAkd+79lfrmXN8=; b=WBAcu7QIzppS2gOh5ClUzLwPihPErvFZz9BpdcUXTuv6kipssjeUeCvOxodO0QdJs/ OoaEX4ECzqzpZzXSmK39Qj4okkcyqi9BYmDiqfS+oLUi/BHvcFd2jkvU9DW/CIVMFGrM PjdXq+BN5lUXzN6sr5aahH36jOO3jp/RjEM3dJAdlHxmv4Ln7bkelEjomimOIdpAd/bj uqwB5MceDUgtufjGZyfz4A22DFfidCwTSfDI3C/cIf9XBb+cRc9BpRlHBE6jecLWX+MK 3rJxazAbL8YpN/N9Btvw87MSyZT0oaKybwI6JjC5fTvSoZgdl5F9WKaDWz7IYgAn/aiO II+w== X-Gm-Message-State: AOAM532XHpsHhxnz817gmy8I5k8zhoXSk5cWqG3RGKaPeWi9hVy3MeyJ W7lrow3XAmu15P7WxuxE8lKXk11UHccUhTO2Nskpzg== X-Google-Smtp-Source: ABdhPJzI7upZPJXAS/U/BdVVBRF1OnrRg9JuFc34xhyTp5JqRpZB51nTuh252JugFoMvxI/WmEtsfkHWbHiX5evyBck= X-Received: by 2002:ab0:64c1:: with SMTP id j1mr1071058uaq.75.1591209732698; Wed, 03 Jun 2020 11:42:12 -0700 (PDT) MIME-Version: 1.0 References: <5C2C810C-FE93-4E32-9FD9-A685F2380629@tzi.org> <9996BD7E-1E2C-4CAA-AC8D-3261DF4EC74B@island-resort.com> In-Reply-To: <9996BD7E-1E2C-4CAA-AC8D-3261DF4EC74B@island-resort.com> From: Ira McDonald Date: Wed, 3 Jun 2020 14:41:59 -0400 Message-ID: To: Laurence Lundblade Cc: Carsten Bormann , cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000e175ed05a732625a" Archived-At: Subject: Re: [Cbor] [cbor-wg/CBORbis] Section 7.1 and IANA considerations. (#196) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 18:42:15 -0000 --000000000000e175ed05a732625a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for lower half of tag space On Wed, Jun 3, 2020 at 2:38 PM Laurence Lundblade wrote: > Was thinking the space for specification required was too small myself th= e > other day. Looks like no conflict with existing registrations. So yes. > > LL > > > > On Jun 3, 2020, at 7:25 AM, Carsten Bormann wrote: > > > > I just submitted a pull request that addresses some comments on Section > 7.1, extension points. > > I used the occasion to pick up the idea to move the lower half of the > 1+2 tag space (256 to 32767) to specification required. > > > > Comments on this? > > > >> You can view, comment on, or merge this pull request online at: > >> > >> https://github.com/cbor-wg/CBORbis/pull/196 > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor > --000000000000e175ed05a732625a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
+1 for lower half of tag s= pace


On= Wed, Jun 3, 2020 at 2:38 PM Laurence Lundblade <lgl@island-resort.com> wrote:
Was thinking the space for specifica= tion required was too small myself the other day. Looks like no conflict wi= th existing registrations. So yes.

LL


> On Jun 3, 2020, at 7:25 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
> I just submitted a pull request that addresses some comments on Sectio= n 7.1, extension points.
> I used the occasion to pick up the idea to move the lower half of the = 1+2 tag space (256 to 32767) to specification required.
>
> Comments on this?
>
>> You can view, comment on, or merge this pull request online at: >>
>>=C2=A0 https://github.com/cbor-wg/CBORbis/pull/1= 96
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
--000000000000e175ed05a732625a-- From nobody Fri Jun 5 08:13:09 2020 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 5C38E3A078C for ; Fri, 5 Jun 2020 08:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ7UvWekgQ3K for ; Fri, 5 Jun 2020 08:13:06 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559F33A078A for ; Fri, 5 Jun 2020 08:13:06 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id hE1pjEFZMOBCghE1pjzMBw; Fri, 05 Jun 2020 08:13:05 -0700 X-CMAE-Analysis: v=2.3 cv=RoC70xuK c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=VkA9zdAzIxSP5rL2CGsA:9 a=QEXdDO2ut3YA:10 a=zIIKu-7Qwl4Dx_hJ:21 a=_W_S_7VecoQA:10 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=jd6J4Gguk5HxikPWLKER:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_8C08CB1D-15C6-414A-9735-0162E36A8A64" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> Date: Fri, 5 Jun 2020 08:13:04 -0700 To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfM/LUCfvXfxauzAPo7EpaasY4oyNYF9HGw1178z3hvF6rzUBIBq9DdnG/PZh2/OMsKwiuQXXhI6sai6gUGJJRJMAkHXR/ih8sUK9K6h7Jxgf8IAHZ3gO 6JBYf4clafzsJIqQ2CokaBDGx8G1v4eZzkYHIWU85Dxjo9J6UZTwi5XM Archived-At: Subject: [Cbor] tag 24, CBOR sequence and non-CBOR sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 15:13:07 -0000 --Apple-Mail=_8C08CB1D-15C6-414A-9735-0162E36A8A64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s some example of CBOR sequence (e.g., = application/cbor-seq) and CBOR that is not a sequence (e.g., = application/cbor) 0x00=20 This is a legal sequence or non-sequence 0x00 0x00 This is a legal sequence, but not non-sequence. A non-sequence can = contain only one data item, this contains two. 0x82 0x00 0x00 This is a legal sequence or non-sequence. It is how you encode two zeros = as a non-sequence. Looks to me that tag 24 cannot contain a CBOR sequence. It says =E2=80=9Ca= data item=E2=80=9D. The use of =E2=80=9Ca=E2=80=9D implies one data = item and thus not a sequence. That means a decoder should always = consider a sequence in the contents of a tag 24 invalid. This seems overly restrictive and unfortunate to me. Would it be wrong = for a generic decoder to allow this? The wording for tag 55799 avoids the issue of sequence or not. Technically, it seems that something labeled application/cbor or in a = file named foo.cbor can=E2=80=99t contain the CBOR 0x00 0x00 because it = is not a legal non-sequence. That might implies a generic decoder should = have a sequence mode and a non-sequence mode. In practice this doesn=E2=80= =99t seem like a very useful restriction. What is useful is whether the = encoded CBOR is legal for the protocol being implemented. =46rom what I=E2=80=99ve experienced, it seems easier if everything is = just a CBOR sequence and no distinction is made. Individual CBOR = protocols can decide on their own structure either deciding to bind = things together in an array or not. Am I missing something? LL --Apple-Mail=_8C08CB1D-15C6-414A-9735-0162E36A8A64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Here=E2=80=99s some = example of CBOR sequence (e.g., application/cbor-seq) and CBOR that is = not a sequence (e.g., application/cbor)

0x00 
This is a legal sequence or non-sequence

0x00 0x00
This is a legal sequence, but not non-sequence. A = non-sequence can contain only one data item, this contains = two.

0x82 0x00 = 0x00
This is a legal sequence or = non-sequence. It is how you encode two zeros as a = non-sequence.

Looks to me that tag 24 cannot contain = a CBOR sequence. It says =E2=80=9Ca data item=E2=80=9D. The use of = =E2=80=9Ca=E2=80=9D implies one data item and thus not a sequence. That = means a decoder should always consider a sequence in the contents of a = tag 24 invalid.

This seems overly restrictive and unfortunate to me. =  Would it be wrong for a generic decoder to allow this?

The wording for tag = 55799 avoids the issue of sequence or not.


Technically, it seems that something labeled application/cbor = or in a file named foo.cbor can=E2=80=99t contain the CBOR 0x00 0x00 = because it is not a legal non-sequence. That might implies a generic = decoder should have a sequence mode and a non-sequence mode. In practice = this doesn=E2=80=99t seem like a very useful restriction. What is useful = is whether the encoded CBOR is legal for the protocol being = implemented.

=46rom what I=E2=80=99ve experienced, = it seems easier if everything is just a CBOR sequence and no distinction = is made. Individual CBOR protocols can decide on their own structure = either deciding to bind things together in an array or not. Am I missing = something?

LL






= --Apple-Mail=_8C08CB1D-15C6-414A-9735-0162E36A8A64-- From nobody Fri Jun 5 11:50:31 2020 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 5927E3A0A69 for ; Fri, 5 Jun 2020 11:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cItLcY_KzNbN for ; Fri, 5 Jun 2020 11:50:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDD23A09DB for ; Fri, 5 Jun 2020 11:50:24 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49dsCc3jT2zySF; Fri, 5 Jun 2020 20:50:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> Date: Fri, 5 Jun 2020 20:50:20 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 613075820.014277-52a07baf3a8db177082ec788e8522c80 Content-Transfer-Encoding: quoted-printable Message-Id: <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] tag 24, CBOR sequence and non-CBOR sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 18:50:30 -0000 Hi Laurence, > On 2020-06-05, at 17:13, Laurence Lundblade = wrote: >=20 > Here=E2=80=99s some example of CBOR sequence (e.g., = application/cbor-seq) and CBOR that is not a sequence (e.g., = application/cbor) >=20 > 0x00=20 > This is a legal sequence or non-sequence =E2=80=9CCBOR data item=E2=80=9D (or =E2=80=9Cencoded CBOR data item=E2=80= =9D) is my preferred wording for the latter. >=20 > 0x00 0x00 > This is a legal sequence, but not non-sequence. A non-sequence can = contain only one data item, this contains two. Right. > 0x82 0x00 0x00 > This is a legal sequence or non-sequence. It is how you encode two = zeros as a non-sequence. Right. > Looks to me that tag 24 cannot contain a CBOR sequence. Indeed, no. > It says =E2=80=9Ca data item=E2=80=9D. The use of =E2=80=9Ca=E2=80=9D = implies one data item and thus not a sequence. That means a decoder = should always consider a sequence in the contents of a tag 24 invalid. (A sequence that doesn=E2=80=99t happen to contain exactly one data = item.) > This seems overly restrictive and unfortunate to me. Would it be = wrong for a generic decoder to allow this? Yes. (Well, it might not be checking the validity.) It seems we forgot to define an equivalent to tag 24 in RFC 8742. But a registration for such a tag can easily be made now. > The wording for tag 55799 avoids the issue of sequence or not. >=20 >=20 > Technically, it seems that something labeled application/cbor or in a = file named foo.cbor can=E2=80=99t contain the CBOR 0x00 0x00 because it = is not a legal non-sequence. Correct. > That might implies a generic decoder should have a sequence mode and a = non-sequence mode. Yes. You can always use the sequence mode, though (just check that you = got exactly one data item back). My preferred API asks the generic decoder to decode one CBOR data item = from a position given and returns the position of the first input byte = beyond that CBOR data item. A sequence decoder is built trivially from this. But you can also use it for cases where a CBOR data item is the = =E2=80=9Cheader=E2=80=9D for some blob that is not decoded as CBOR. > In practice this doesn=E2=80=99t seem like a very useful restriction. = What is useful is whether the encoded CBOR is legal for the protocol = being implemented. If the protocol wants one CBOR data item and gets two (or zero), that = doesn=E2=80=99t help. > =46rom what I=E2=80=99ve experienced, it seems easier if everything is = just a CBOR sequence and no distinction is made. Individual CBOR = protocols can decide on their own structure either deciding to bind = things together in an array or not. Am I missing something? I think the important observation is that it took us a couple of years = to rationalize the weird text about =E2=80=9Cstreaming decoders=E2=80=9D = in RFC 7049 into a clear concept of CBOR sequences. So there is a lot of code out that that doesn=E2=80=99t cope very well = with CBOR sequences, just with single CBOR data items =E2=80=94 and that = is often also exactly what=E2=80=99s needed. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jun 6 12:42:09 2020 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 AA51E3A0B0A for ; Sat, 6 Jun 2020 12:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TS_SaV085eU for ; Sat, 6 Jun 2020 12:42:07 -0700 (PDT) Received: from p3plsmtpa09-04.prod.phx3.secureserver.net (p3plsmtpa09-04.prod.phx3.secureserver.net [173.201.193.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8543A0B07 for ; Sat, 6 Jun 2020 12:42:07 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id hehijyTWIpfF2hehijA1MF; Sat, 06 Jun 2020 12:42:06 -0700 X-CMAE-Analysis: v=2.3 cv=NLWrBHyg c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=o3LS-OQVB9i6saUIs9QA:9 a=xpyytPA2zsbDlgyd:21 a=46bGI_CoPwGvhCWo:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Laurence Lundblade In-Reply-To: <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> Date: Sat, 6 Jun 2020 12:42:06 -0700 Cc: cbor@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfK5rOG/D8oM4lYk3jYw/oYT0NSM/0cSiBKx7jZdJNcwIKJqbyNLXVQNp5WKGP7UUtytO0lSlTe+I2PU6kozn2PjFYsyP/nPEfTzymq/lWGIfAepBOTYh 3R3JnzKorvM+c78sMyo82CWBeshEEqw1+IODOzzycknXY0+cWeq9thA5mpy8XhUGfdKR222wSrMSwg== Archived-At: Subject: Re: [Cbor] tag 24, CBOR sequence and non-CBOR sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 19:42:09 -0000 Well glad I asked.=20 > On Jun 5, 2020, at 11:50 AM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 >> On 2020-06-05, at 17:13, Laurence Lundblade = wrote: >>=20 >> Here=E2=80=99s some example of CBOR sequence (e.g., = application/cbor-seq) and CBOR that is not a sequence (e.g., = application/cbor) >>=20 >> 0x00=20 >> This is a legal sequence or non-sequence >=20 > =E2=80=9CCBOR data item=E2=80=9D (or =E2=80=9Cencoded CBOR data = item=E2=80=9D) is my preferred wording for the latter. >=20 >>=20 >> 0x00 0x00 >> This is a legal sequence, but not non-sequence. A non-sequence can = contain only one data item, this contains two. >=20 > Right. >=20 >> 0x82 0x00 0x00 >> This is a legal sequence or non-sequence. It is how you encode two = zeros as a non-sequence. >=20 > Right. >=20 >> Looks to me that tag 24 cannot contain a CBOR sequence. >=20 > Indeed, no. How about stating it like this? While tag 24 can contain a sequence of = length one, it cannot contain most sequences as defined in 8742.=20 Personally, I=E2=80=99d prefer to just say tag 24 can=E2=80=99t contain = sequences. That way you=E2=80=99d have tag 24 for non-sequences and new = tag XX for sequences. You don=E2=80=99t want people designing a protocol = that uses sequences and using tag 24 when the sequence happens to be = length 1 and tag XX when it is larger. That=E2=80=99s just confusing and = more code. Basically a protocol designer should either design a protocol that uses = sequences or one that doesn=E2=80=99t and declare that up front. If some = messages in a sequence-based protocol happen to be just one item, they = are still part of a sequence-based protocol. >=20 >> It says =E2=80=9Ca data item=E2=80=9D. The use of =E2=80=9Ca=E2=80=9D = implies one data item and thus not a sequence. That means a decoder = should always consider a sequence in the contents of a tag 24 invalid. >=20 > (A sequence that doesn=E2=80=99t happen to contain exactly one data = item.) >=20 >> This seems overly restrictive and unfortunate to me. Would it be = wrong for a generic decoder to allow this? >=20 > Yes. > (Well, it might not be checking the validity.) >=20 > It seems we forgot to define an equivalent to tag 24 in RFC 8742. > But a registration for such a tag can easily be made now. >=20 >> The wording for tag 55799 avoids the issue of sequence or not. >>=20 >>=20 >> Technically, it seems that something labeled application/cbor or in a = file named foo.cbor can=E2=80=99t contain the CBOR 0x00 0x00 because it = is not a legal non-sequence. >=20 > Correct. >=20 >> That might implies a generic decoder should have a sequence mode and = a non-sequence mode. >=20 > Yes. You can always use the sequence mode, though (just check that = you got exactly one data item back). >=20 > My preferred API asks the generic decoder to decode one CBOR data item = from a position given and returns the position of the first input byte = beyond that CBOR data item. > A sequence decoder is built trivially from this. > But you can also use it for cases where a CBOR data item is the = =E2=80=9Cheader=E2=80=9D for some blob that is not decoded as CBOR. QCBOR is a more powerful generic decoder than the one implied by the API = you describe. It aims to relieve the protocol implementor of a lot of = these details and hard-to-understand aspects of CBOR. It aims to make = the work of the protocol implementor a lot easier. As a shared library = it reduces overall object code because it handles things common to many = protocols (e.g. duplicate detection (coming soon)). It=E2=80=99s of course fine to have all different sorts of decoders. I find the distinction between sequences and non-sequence subtle and it = took until this conversation about tag 24 (started by mcr) to really get = it sharp for me. It was definitely one of the things that was confusing = to me when I started working with CBOR a few years ago. Easy to gloss = over in a way, but a niggling issue that finally came to light. Seems = like it wasn=E2=80=99t just me. One of the reasons I try to do more in QCBOR is to help others get these = kinds of details right. They are hard to to understand from the RFCs. = The average protocol implementor won=E2=80=99t spend the five plus years = reading them we all have here. >=20 >> In practice this doesn=E2=80=99t seem like a very useful restriction. = What is useful is whether the encoded CBOR is legal for the protocol = being implemented. >=20 > If the protocol wants one CBOR data item and gets two (or zero), that = doesn=E2=80=99t help. Protocol implementors have to deal with lots of errors. >=20 >> =46rom what I=E2=80=99ve experienced, it seems easier if everything = is just a CBOR sequence and no distinction is made. Individual CBOR = protocols can decide on their own structure either deciding to bind = things together in an array or not. Am I missing something? >=20 > I think the important observation is that it took us a couple of years = to rationalize the weird text about =E2=80=9Cstreaming decoders=E2=80=9D = in RFC 7049 into a clear concept of CBOR sequences. > So there is a lot of code out that that doesn=E2=80=99t cope very well = with CBOR sequences, just with single CBOR data items =E2=80=94 and that = is often also exactly what=E2=80=99s needed. QCBOR is fine with sequences or not as input. The CBOR playground = doesn=E2=80=99t allow sequences. Personally, I still think it would be better to relax the distinction = and allow tag 24 to carry sequences rather than define a new tag. It is = a broadening, not a narrowing so it doesn=E2=80=99t break anything. = There=E2=80=99s no backwards compatibility issue just like there was no = backwards compatibility issue for 7049 when 8742 was published.=20 If not relaxing the distinction and a new tag is defined for 8742, maybe = 3.4.5.1 should say that 8742 CBOR sequences are invalid as content for = tag 24. It is OK for CBORbis to make normative reference to 8742. LL From nobody Sun Jun 7 11:22:57 2020 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 813E53A07D0 for ; Sun, 7 Jun 2020 11:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnNtmlM5qtEy for ; Sun, 7 Jun 2020 11:22:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9373A07CE for ; Sun, 7 Jun 2020 11:22:52 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49g4Vn1N2yzydW; Sun, 7 Jun 2020 20:22:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> Date: Sun, 7 Jun 2020 20:22:40 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 613246960.479568-0a6b460dd1ca2e92ed6df280ea0f0475 Content-Transfer-Encoding: quoted-printable Message-Id: <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] tag 24, CBOR sequence and non-CBOR sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 18:22:57 -0000 Hi Laurence. >=20 > How about stating it like this? We could, but stating for every encoded CBOR data item that it is not = intended to allow CBOR sequences with 0, 2, or more encoded CBOR data = items in them strikes me as confusing. If I read a book about tomatoes, I would be confused if that states = again and again for some content that that does not apply to apples. > While tag 24 can contain a sequence of length one, it cannot contain = most sequences as defined in 8742.=20 Yes, and we can be abundantly clear about that, see PR #200. Without mentioning CBOR sequences. [=E2=80=A6] > QCBOR is fine with sequences or not as input. That is certainly a valid way to do things, but that should be made = obvious at the API. > The CBOR playground doesn=E2=80=99t allow sequences. Right, because it was written before we got a handle on how useful = sequences are as a separate concept. > Personally, I still think it would be better to relax the distinction = and allow tag 24 to carry sequences rather than define a new tag. That would add some confusion between CBOR data items and CBOR = sequences, so for me that would be a change for the worse. > It is a broadening, not a narrowing so it doesn=E2=80=99t break = anything. There=E2=80=99s no backwards compatibility issue just like = there was no backwards compatibility issue for 7049 when 8742 was = published.=20 There is a backwards compatibility issue: Without the change, both sides = of the communication can rely to get what they expect =E2=80=94 one CBOR = data item. After the change, new implementations might start to send = two, and that kills backwards compatibility with old implementations. > If not relaxing the distinction and a new tag is defined for 8742, = maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as content = for tag 24. It does so (and more so with #200), but not with these exact words. > It is OK for CBORbis to make normative reference to 8742. Actually, no (that would be a downref). But that did not stop us from = putting in informative references. I just don=E2=80=99t think we need = another one here; PR #200 is about as far as we want to go here before = we add confusion. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 9 15:00:34 2020 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 97D773A0953; Tue, 9 Jun 2020 15:00:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159174002155.20590.13492723858967645797@ietfa.amsl.com> Date: Tue, 09 Jun 2020 15:00:21 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-01.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 22:00:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-01.txt Pages : 5 Date : 2020-06-09 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applications needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-01 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 9 16:48:48 2020 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 826943A0C97 for ; Tue, 9 Jun 2020 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIr9VwB0dUz5 for ; Tue, 9 Jun 2020 16:48:43 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640130.outbound.protection.outlook.com [40.107.64.130]) (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 B99083A0C92 for ; Tue, 9 Jun 2020 16:48:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jtfRBVxrHY5FwR3AFtuW3kaXZJhnZnGLuvMsqCfGUX1brRTgY79opX5ZoprbBNIslX4PmV1++ouI7vVfXgfxQeI0jyzdk37JgXDicRfxcVQDYzH/xdyIIpNIvEVgWHIjU7of//5aYhk3xupg4dr2d5X8K7VE71vLedcYya80wCHyYY/UwVL4mQylodTC4n5JQGI7iQZOlcEmK+KFfAXmiiyrprtYI40yiYKRJcPB2Q8qvjxkGvEqsFpp9UOG09rKUw8F5f2QnzDOoZL1j2tfMzM0MqbBGB+jYqRUleByrs3riPhiWRFZWr/svWoYGu/6I49y/ATCd3Y2rasFvXEhaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=65Yejm/Yuc6Z7923JoRsEhUIBCCEqtSCYBY2okGjabo=; b=I0DJpOba95fYdNQ5kgkhL0LLWgIufJmQyehPGnx4tRuRKEuINfBS+NWA/udDjjbe7UAYHUcmIxDId1VLl+ukeaE/w1hUuJrfQpBgJvaE2Z/OOImw8n0vEwPDtmjBz5vdYlDJ0fK0q6oh0raEW1zX2LPLnUomUXJDXSgw++FInXWrgtWPUxMV+asjSYxyIK7uixiV+v17jzAcB35vjqQrczBV3+M9Z7JCtCasMHl8FFBnc0dA11bhMNzeI642korAhkiAtT90s/cbg7cVe0u3jV7+UEhYRomuBzhB1h37HEg2QBnni3sj2k6Nbwaw5Q/E1VU0OijeXqWE+b5z9TN6VQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=65Yejm/Yuc6Z7923JoRsEhUIBCCEqtSCYBY2okGjabo=; b=exF6ITOuulAPEeqKUzqST/+8Sp24Zn6TQAo406hGLG5as2sOIUqByRvWu0TuaoQ5K1HjKc1kObEbwH9TrozM9wd8FGJ0Dk8i8xJ8ZDgJLKcbsktihmyJqOYbsgQPxbtgRAORu6BzCpJcVsBZeTYL4SmGwJL+sawOf330+W8Kn2M= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0783.namprd00.prod.outlook.com (2603:10b6:5:1bd::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3116.0; Tue, 9 Jun 2020 23:48:42 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6%7]) with mapi id 15.20.3124.000; Tue, 9 Jun 2020 23:48:42 +0000 From: Mike Jones To: "cbor@ietf.org" Thread-Topic: CBOR Tags for Date Registered Thread-Index: AdY+rSD0xnfO8ncLTyCa/YGcfYhlww== Date: Tue, 9 Jun 2020 23:48:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=bc447f08-713b-4b90-9123-0000cf421a2c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-09T22:27:04Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a7c354ec-2880-411b-d4e9-08d80ccfa40c x-ms-traffictypediagnostic: DM6PR00MB0783: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U5G1NmTyi/XvZFMNoY2t7im9f/evu8FriWL9u6HC3L3Mkc3l7Ui4g4IooiLyZaq2XIpxqcQt+L5GibxqOZCIduG+HD0LgL2+CQrCwXAqx/R5K8Zw8pE9Z18qJ/6xrGJbTcAlTDtlWGJHEbr8Jdknhtjp5cZJ+jlIDrFEwa1LmkUFzsSA1sBLcw9pHWaftkj1t8MQDCC0R+g5LX1tGttpFgC/dooA2OBGIf4RI4j1uAooHlva7AmEVKzT4Ddy1XxogaZceD36vOOVe5WZZEoZOgR7ie70ljFjkr7oT/OxFH6BJ5RgK+f9fCfxi3PFifprT1sRYY2NuNtK5C/uBFsX+kzZOoTHj4cAVlZHdmFKXkzvEmbVQspwoCnKeRCWvOSnWmkU/TrmkSO3V9YjPth76VZx5g6dGbP72Wko3TGaPVustR+rKAMbvTrOilLfYZzXc6sW+Cq+eFqaJxDqy2ZyVw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(186003)(64756008)(8990500004)(5660300002)(8936002)(71200400001)(26005)(66476007)(8676002)(316002)(66946007)(2906002)(76116006)(66556008)(66446008)(21615005)(82950400001)(9686003)(7696005)(478600001)(966005)(33656002)(6916009)(55016002)(6506007)(166002)(52536014)(83380400001)(86362001)(82960400001)(10290500003)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: jE6xQCU3LBn+3XjAcyyGxqpWVCKxX2KWdqRI8wg/6nNk3vgvWRj1SA1D6MTemecjUfqmN+/IXRrXFJu4WzkHgfdgp1pXHEAaI1mzGwGk5ISyvCB24awTnMyZP9z1HWYPfjeHbYL/WxBt5slVHBnDMEoVDTf7N+n5CYTc01jOM6vqtsjYWGE1ZbV5ljDBJV/Wk3w1y2pfwnMRB9nFf4mmoaE0Wblqpg44AbjWcLADrXGBZ35d2vT8gpl55sbiyffO9291CMQ+vYYt+OSoJN59jWcM3DqKUgWkZ4CLHfx9sdedELjKnZYuvURGoFLwTg0NM50ErTCA7OE3DF3cICzy8Vy9m9OEHzc2l+f0+DWBFC0l9sap8GhcclkF2O9eEd+kvjey8re49VQ49PsQOe+AYrN0Jy7KXoPoSSx9Ki4fOvTiEMZ7b8rYxNjllXeUzJmieJEjvZijhKeD2fQL3ojLx/FKcpMwWrWsxNa+03Gw0uM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06842180A195835162B80F4DF5820DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7c354ec-2880-411b-d4e9-08d80ccfa40c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 23:48:42.1828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 80FsmHh6icfoXQ6mxEYpGq3WJkORJBBK7mSVPMtXTrCKO87NNXVaT7rFUEPtH5c/gyWs8zqs0PevmAtdexUzlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0783 Archived-At: Subject: [Cbor] CBOR Tags for Date Registered X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 23:48:46 -0000 --_000_DM6PR00MB06842180A195835162B80F4DF5820DM6PR00MB0684namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The CBOR tags for the date representations defined by the "Concise Binary O= bject Representation (CBOR) Tags for Date" specification have been register= ed in the IANA Concise Binary Object Representation (CBOR) Tags registry. This means that= they're now ready for use by applications. In particular, the full-date t= ag requested for use by the ISO Mobile Driver's License specification in th= e ISO/IEC JTC 1/SC 17 "Cards and = security devices for personal identification" working group is now good to = go. FYI, I also updated the spec to incorporate a few editorial suggestions by = Carsten Bormann. The new draft changed "positive or negative" to "unsigned= or negative" and added an implementation note about the relationship to Mo= dified Julian Dates. Thanks Carsten, for the useful feedback, as always! It's my sense that the spec is now ready for working group last call in the= CBOR Working Group. The updated specification is available at: * https://tools.ietf.org/html/draft-ietf-cbor-date-tag-01 An HTML-formatted version is also available at: * https://self-issued.info/docs/draft-ietf-cbor-date-tag-01.html -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2101 and= as @selfissued. --_000_DM6PR00MB06842180A195835162B80F4DF5820DM6PR00MB0684namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The CBOR tags for the date representations defined b= y the “Concise Binary Object Representation (CBOR) Tags for Date” specification have been registered in the IANA= Concise Binary Object Representation (CBOR) Tags registry.  This = means that they’re now ready for use by applications.  In partic= ular, the full-date tag re= quested for use by the ISO Mobile Driver’s License specification in t= he ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification” work= ing group is now good to go.

 

FYI, I also updated the spec to incorporate a few ed= itorial suggestions by Carsten Bormann.  The new draft changed "p= ositive or negative" to "unsigned or negative" and added an = implementation note about the relationship to Modified Julian Dates.  Thanks Carsten, for the useful feedback, as always!

 

It’s my sense that the spec is now ready for w= orking group last call in the CBOR Working Gro= up.

 

The updated specification is available at:

--_000_DM6PR00MB06842180A195835162B80F4DF5820DM6PR00MB0684namp_-- From nobody Thu Jun 11 11:48:31 2020 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 E1C913A0D39; Thu, 11 Jun 2020 11:48:28 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpAWNSGjE7D3; Thu, 11 Jun 2020 11:48:27 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF133A0D38; Thu, 11 Jun 2020 11:48:27 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jun 2020 11:48:21 -0700 From: Jim Schaad To: CC: Date: Thu, 11 Jun 2020 11:48:19 -0700 Message-ID: <01e201d64020$e163bef0$a42b3cd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZAGVM0Vwu/DKL9RduxQ6BV+law5A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 18:48:29 -0000 * Is there any chance that you can upgrade to using the v3 of xml2rfc schema? If not then there is not an issue as the RFC Editor will do it. * Introduction: I prefer the abstract form of /date but not a time/date without a time/ * While this is something that is clear to me, I got a recent comment when I suggested that this be used elsewhere of, "But how does this work with time zones?". Based on that I think that there needs to be some text about why time zones are not of interest here. * Section 3- I think that the second paragraph would be wise to distinguish between a point in time and a date when looking at access control decisions. Jim From nobody Thu Jun 11 12:43:53 2020 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 22D153A0859 for ; Thu, 11 Jun 2020 12:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjn8ELmkJB1K for ; Thu, 11 Jun 2020 12:43:49 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C96D3A0853 for ; Thu, 11 Jun 2020 12:43:49 -0700 (PDT) Received: from [172.16.8.18] ([65.117.83.146]) by :SMTPAUTH: with ESMTPA id jT75jBhp15tuZjT76jnidA; Thu, 11 Jun 2020 12:43:48 -0700 X-CMAE-Analysis: v=2.3 cv=Ge9pYjfL c=1 sm=1 tr=0 a=UU+Bnaz6nmwnxJQnjP64Rg==:117 a=UU+Bnaz6nmwnxJQnjP64Rg==:17 a=gKmFwSsBAAAA:8 a=48vgC7mUAAAA:8 a=1L6JZKL0Swk7oCFmaxEA:9 a=pt55JNqjyBiVD2sS:21 a=BYM4iphGW9fRrQr2:21 a=QEXdDO2ut3YA:10 a=ijLDYO8zWVDveXBz4s4A:9 a=8DcYrs2GPElf5DGL:21 a=BOtuDcPl6UPecxok:21 a=s15D-nkycCsJ8XBS:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_150C2F8F-74A4-4987-B276-3C47ECEB81CC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 12:43:47 -0700 In-Reply-To: <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfDs1wh9atavVT8AZB7Y6Rk7BqKFut0nj2qDIFJXyDs2JEkbN6PQigBxGFaphX+avqb2uNRTapVCic/pzJojHZizV7KwmXvggd1yNBQlsbpG8XRfqpJqA PAOzD+DiZqPNGz+jnE574S1sMLKk+SSHCoS0V3tA36L+/w63lN9cH042JkgTse0Lh9C1hvUX4MQs8Q== Archived-At: Subject: Re: [Cbor] tag 24, CBOR sequence and non-CBOR sequence X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:43:52 -0000 --Apple-Mail=_150C2F8F-74A4-4987-B276-3C47ECEB81CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Carsten, One could say CBOR protocol world is bifurcated into sequence protocols = and single-item protocols, but it=E2=80=99s more complex than that = because a CBOR protocol that has both could be defined. And there is the = 55799 tag which allows either a sequence or single item.=20 To be abundantly clear, I=E2=80=99m tempted to write of this in CBOR = protocol design considerations. Was thinking that COSE payload was similar to 55799 in allowing both, = but it is actually another thing entirely. It is not tag 24 or any other = tag. It uses the MIME / COAP typing system which can indicate CBOR or = CBOR sequence or name some other protocol that then in turn indicates = which. I don=E2=80=99t know what the advantage of this variability and = complexity is. Wouldn=E2=80=99t be simpler for the CBOR world if = sequences were the only thing? They are a super-set of single items. The = only thing I can think of is that this complexity allows some decoders = to be a little simpler by omitting support for sequences. But, it seems the main reason is that no one thought about this in = detail until recently (me included; in theory I should have about four = years ago when I started on QCBOR :-) ) What do you think of this as a way forward to reduce the complexity a = little?=20 Define a new standard tag alternate to tag 24 the content of which is a = sequence (as planned). A CBOR sequence is always able to carry a single item, therefore = encourage use of this new tag and the MIME and COAP types for sequences = over the ones for single items. Encourage CBOR decoders to support sequences. I don=E2=80=99t see these types and tags as part of the mechanism that = sets requirements for decoders implementing protocols. If you are going = to implement a CBOR protocol, you have to know if it is a single-item = protocol or sequence protocol and you have to select a CBOR decoder that = can handle the protocol. That decision is made when code is written, not = when a typed/tagged blob of CBOR arrives.=20 Any implementation of a single-item protocol must deal with extra bytes = to do a good job. Just because something has tag 24 doesn=E2=80=99t mean = it won=E2=80=99t have some extra bytes (that might be CBOR), so the tag = doesn=E2=80=99t defend against or relieve the decoder of this work. Agreed there is a backwards compatibility issue in allowing sequence in = tag 24, but it is only for decoders that explicitly check that there is = only a single item in the content of tag 24 in their very explicit = implementation of tag 24. If they just hand the contents of tag 24 to = the next level protocol decoder there would be no backwards = compatibility issue in practice. I suspect most implementations of tag = 24 don=E2=80=99t pre-check its contents before handing it off. =20 I don=E2=80=99t want to implement tag 24 with that check for a single = item because it adds code and seems like code that is not particularly = necessary given the implementation of the decoding of the content will = pretty much have to perform that check too as part of the protocol = decoding it does. I will probably just treat tag 24 and the new sequence = tag the same way and allow sequences in either. I can=E2=80=99t see a = downside to doing that. LL > On Jun 7, 2020, at 11:22 AM, Carsten Bormann wrote: >=20 > Hi Laurence. >=20 >>=20 >> How about stating it like this? >=20 > We could, but stating for every encoded CBOR data item that it is not = intended to allow CBOR sequences with 0, 2, or more encoded CBOR data = items in them strikes me as confusing. >=20 > If I read a book about tomatoes, I would be confused if that states = again and again for some content that that does not apply to apples. >=20 >> While tag 24 can contain a sequence of length one, it cannot contain = most sequences as defined in 8742.=20 >=20 > Yes, and we can be abundantly clear about that, see PR #200. > Without mentioning CBOR sequences. >=20 > [=E2=80=A6] >> QCBOR is fine with sequences or not as input. >=20 > That is certainly a valid way to do things, but that should be made = obvious at the API. >=20 >> The CBOR playground doesn=E2=80=99t allow sequences. >=20 > Right, because it was written before we got a handle on how useful = sequences are as a separate concept. >=20 >> Personally, I still think it would be better to relax the distinction = and allow tag 24 to carry sequences rather than define a new tag. >=20 > That would add some confusion between CBOR data items and CBOR = sequences, so for me that would be a change for the worse. >=20 >> It is a broadening, not a narrowing so it doesn=E2=80=99t break = anything. There=E2=80=99s no backwards compatibility issue just like = there was no backwards compatibility issue for 7049 when 8742 was = published.=20 >=20 > There is a backwards compatibility issue: Without the change, both = sides of the communication can rely to get what they expect =E2=80=94 = one CBOR data item. After the change, new implementations might start = to send two, and that kills backwards compatibility with old = implementations. >=20 >> If not relaxing the distinction and a new tag is defined for 8742, = maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as content = for tag 24. >=20 > It does so (and more so with #200), but not with these exact words. >=20 >> It is OK for CBORbis to make normative reference to 8742. >=20 > Actually, no (that would be a downref). But that did not stop us from = putting in informative references. I just don=E2=80=99t think we need = another one here; PR #200 is about as far as we want to go here before = we add confusion. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_150C2F8F-74A4-4987-B276-3C47ECEB81CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Carsten,

One could say CBOR protocol world is bifurcated into sequence = protocols and single-item protocols, but it=E2=80=99s more complex than = that because a CBOR protocol that has both could be defined. And there = is the 55799 tag which allows either a sequence or single = item. 

To = be abundantly clear, I=E2=80=99m tempted to write of this in CBOR = protocol design considerations.

Was thinking that COSE payload was = similar to 55799 in allowing both, but it is actually another thing = entirely. It is not tag 24 or any other tag. It uses the MIME / COAP = typing system which can indicate CBOR or CBOR sequence or name some = other protocol that then in turn indicates which.
I don=E2=80=99t know what the = advantage of this variability and complexity is. Wouldn=E2=80=99t be = simpler for the CBOR world if sequences were the only thing? They are a = super-set of single items. The only thing I can think of is that this = complexity allows some decoders to be a little simpler by omitting = support for sequences.

But, it seems the main reason is that no one thought about = this in detail until recently (me included; in theory I should have = about four years ago when I started on QCBOR :-) )


What do you think of this as a way forward to reduce the = complexity a little? 

Define a new standard tag = alternate to tag 24 the content of which is a sequence (as = planned).

A = CBOR sequence is always able to carry a single item, therefore encourage = use of this new tag and the MIME and COAP types for sequences over the = ones for single items.

Encourage CBOR decoders to support = sequences.

I don=E2=80=99t see these types and tags as part of the = mechanism that sets requirements for decoders implementing protocols. If = you are going to implement a CBOR protocol, you have to know if it is a = single-item protocol or sequence protocol and you have to select a CBOR = decoder that can handle the protocol. That decision is made when code is = written, not when a typed/tagged blob of CBOR arrives. 

Any implementation of a = single-item protocol must deal with extra bytes to do a good job. Just = because something has tag 24 doesn=E2=80=99t mean it won=E2=80=99t have = some extra bytes (that might be CBOR), so the tag doesn=E2=80=99t defend = against or relieve the decoder of this work.

Agreed there is a backwards = compatibility issue in allowing sequence in tag 24, but it is only for = decoders that explicitly check that there is only a single item in the = content of tag 24 in their very explicit implementation of tag 24. If = they just hand the contents of tag 24 to the next level protocol decoder = there would be no backwards compatibility issue in practice.  I = suspect most implementations of tag 24 don=E2=80=99t pre-check its = contents before handing it off.  

I don=E2=80=99t want to implement tag = 24 with that check for a single item because it adds code and seems like = code that is not particularly necessary given the implementation of the = decoding of the content will pretty much have to perform that check too = as part of the protocol decoding it does. I will probably just treat tag = 24 and the new sequence tag the same way and allow sequences in either. = I can=E2=80=99t see a downside to doing that.

LL


On Jun = 7, 2020, at 11:22 AM, Carsten Bormann <cabo@tzi.org> wrote:

Hi = Laurence.


How about stating it like this?

We could, but stating for every = encoded CBOR data item that it is not intended to allow CBOR sequences = with 0, 2, or more encoded CBOR data items in them strikes me as = confusing.

If I read a book about tomatoes, = I would be confused if that states again and again for some content that = that does not apply to apples.

While tag 24 can contain = a sequence of length one, it cannot contain most sequences as defined in = 8742.

Yes, and we can be = abundantly clear about that, see PR #200.
Without = mentioning CBOR sequences.

[=E2=80=A6]
QCBOR is fine with = sequences or not as input.

That = is certainly a valid way to do things, but that should be made obvious = at the API.

The CBOR playground doesn=E2=80=99t allow sequences.

Right, because it was written = before we got a handle on how useful sequences are as a separate = concept.

Personally, I still think it would be better to relax the = distinction and allow tag 24 to carry sequences rather than define a new = tag.

That would add some = confusion between CBOR data items and CBOR sequences, so for me that = would be a change for the worse.

It is a broadening, not a narrowing so it = doesn=E2=80=99t break anything. There=E2=80=99s no backwards = compatibility issue just like there was no backwards compatibility issue = for 7049 when 8742 was published.

There is a backwards compatibility issue: Without the change, = both sides of the communication can rely to get what they expect =E2=80=94= one CBOR data item.  After the change, new implementations might = start to send two, and that kills backwards compatibility with old = implementations.

If not relaxing the distinction and a new tag is defined for = 8742, maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as = content for tag 24.

It does so = (and more so with #200), but not with these exact words.
It is OK for CBORbis to = make normative reference to 8742.

Actually, no (that would be a downref).  But that did = not stop us from putting in informative references.  I just don=E2=80= =99t think we need another one here; PR #200 is about as far as we want = to go here before we add confusion.

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

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

= --Apple-Mail=_150C2F8F-74A4-4987-B276-3C47ECEB81CC-- From nobody Fri Jun 12 11:51:56 2020 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 036B53A0433; Fri, 12 Jun 2020 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53mr9Kl204_D; Fri, 12 Jun 2020 11:51:52 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640090.outbound.protection.outlook.com [40.107.64.90]) (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 62E663A053E; Fri, 12 Jun 2020 11:51:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ah/yqWjTSWqWL6NvuWuiqE2Vvys7AOC3PjIiSq1dx3FydiKlRF+WwwZm6Gz0uc2iYDFVDc3aCcSucV05r7RbXDF6vQjJAwQ4Z8jpPvQCanx2N5EFd+6yUjMRDOoP+yuOz1CnSObcvv6bLUUrJil88SysHb355cG0UpwbXnZdr6hSQmDgdT9QtMYD86p5lGCNySD47ioSAM9ss8Qam7NskyAG0pGr2WJNyUhhQrAQJ1EGWLIBcuN7IzKrNVUEcHApfRrLwvYE0VPUUVk34m6P7dW4TdB6yPaa//6Rc5PisgWIWySnH8ILpmTMZUOxFeDeBr1ae4moY7j/lMnUrr3SiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SBD8AvZlY2milhxlAjokrnlxH8CeVkiQUT76+C3EQ0s=; b=MCoKV5b+Um59lsdidn6F+2HZ9hoOhBxhbMdxihwmR4/eEKoQjaSht/4yiddrmi3vw3dF94FcVXoiY2he4GO6FGcWICJYkQfnZtzqqHJQFGQzRRWcNKqVoLME8S8iHNfrY5xLrCZ7EfjiEBPfyu5NXdrZxT7bVmSWqmPt8SBknLbN6RCcP2QXtzb9qxPQckGHdUm/Qd4KlTz/oqFBdMrg+NEL8PUaMYjcwAeMdZVFeAhGZurvnTfo6PsL99pZF7WstPgg556pNOVQkuzIaSIAC87J5PO+Z737LgXQ5s/8iVEDlzGCnAH7+v2arCQG8nCAz/6sh62EMt7DKZnBqwZ2Pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SBD8AvZlY2milhxlAjokrnlxH8CeVkiQUT76+C3EQ0s=; b=RcryjQ+Dt1N5JMPKa9/YkqDUW7yHa/GxZUBF2C3kVAZXyjjFu94elvGrgWLrO93FcQALurRxdn+IQhAjS3k75z2xnxUAWs4cbB1JDzkWWXqzJSRcvSFB+MufIc7TX69zLs/o65qxdM0BfUdRFrc+LHrp4oJCTrgwCMGi+9MqrH8= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0475.namprd00.prod.outlook.com (2603:10b6:5:116::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3133.0; Fri, 12 Jun 2020 18:51:49 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::ca2:60e6:183a:18e1]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::ca2:60e6:183a:18e1%3]) with mapi id 15.20.3136.000; Fri, 12 Jun 2020 18:51:49 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" CC: "cbor@ietf.org" Thread-Topic: Review draft-ietf-cbor-date-tag-01 Thread-Index: AdZA6oYHrsep9MdnQn2dj3B2XcVwEA== Date: Fri, 12 Jun 2020 18:51:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7329b5d3-6b53-42a1-8573-362e5da544a9; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T18:45:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.207.228.81] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 43a3e61f-5c13-4ae6-cc65-08d80f01aa04 x-ms-traffictypediagnostic: DM6PR00MB0475: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: taOuVzWuJVklNpRlp7cM6rTYpUFBr2BdB3XYooQPBfPPgfWT06ltEm0nbusBpdORmYVnc0gNh8QSadul8z9iXbBzuZu7Ce3czNpmamQrL46VW6QN6BlUkbASURbTJ2+Bt9NwkVrR5Pvjm4YcfoC1+tWiefVXZlK9na2pFKH8VMrCOrGh/INO5EhxpYLQsqWztOuAvfxeFoDvqXWAanQAASJG5jIq91hzrg4NYeqzCLxuf8cfuiW0trItzyCBsXnLb9kW7/sKvR3QbGq8N8xLDQxen5GzJAQ+ShfeYVo6jRzqQwiFzJmhPovYHtEuz3HmyuzWgomNw2gqLEuC66DHo6fbto7G2by9HtqX5hvdCiWDq/U0ErpRLhYVXPhzgQj6SKODrJJVdgqoE/Wb1d4bzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(39860400002)(376002)(136003)(396003)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(53546011)(6506007)(71200400001)(52536014)(7696005)(5660300002)(10290500003)(82950400001)(82960400001)(83380400001)(966005)(478600001)(4326008)(9686003)(55016002)(8676002)(316002)(110136005)(8990500004)(26005)(2906002)(186003)(33656002)(8936002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: jcP4vyZ6/hdRmhUkZQRyra7hrTpNDswTkcwxddRGSHaSgdG/19da23zaJdnF3gV4oCcUnVzc+QBihZBvzdq+EqePHFXUHwFoDNCLFaCQZoTh0QFmNdTZfnAIeM5y/i4XNoiWxftKEz+COJ5gjz4Fh9nOis0nyJR5AyK8VZPysM2WkZVsIY2SvG96RW+sy+D41gIbw5m0b67TfjX78rgEohtsckhuT72tyVVbXYEbe7ITJKUJKri4sj3KUtBJ/NoIO4bqJC9Sf0g5anfLPyLIWJ8SS+qjcTEztQZ93Fr9/NYYmYI40vLrjCaw+uXXWERFuL2EdVyRiGm1ie8aLqGFRJXoWgUrHEGSyfbIsvSio+iXPe03y+d3uwitymZpAmNOYs7sRJ4pk/N9ABQDGVsvYXpsvjj76q1HWEyVVGdn9VLQPmMrbNEbu/ywzcS5T/UezxNt5kkF4Ev/rdxCWQ8KTT5H1PwmEwNlYdKwVfKYcMc595+8B/ZANKEkiIGw/QgW x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0684.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43a3e61f-5c13-4ae6-cc65-08d80f01aa04 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 18:51:49.4162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: V+3JOBq1OUiWw/IrEGYfUxkkcEpykfTI+TSHb6trceduaHuk2EhYuXxUJoo3DYB8gNnyMKNwCZFbXYoybweQZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0475 Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 18:51:54 -0000 Thanks for your review, Jim. My replies are inline below... Is it time to start WGLC so others also get their reviews in? I'll note th= at the IANA registrations have already occurred at https://www.iana.org/ass= ignments/cbor-tags/cbor-tags.xhtml. -----Original Message----- From: Jim Schaad =20 Sent: Thursday, June 11, 2020 11:48 AM To: draft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Subject: Review draft-ietf-cbor-date-tag-01 * Is there any chance that you can upgrade to using the v3 of xml2rfc schem= a? If not then there is not an issue as the RFC Editor will do it. I haven't really learned all the ins and outs of the new syntax yet, so I'd= have more confidence with the RFC Editor doing it correctly than me. * Introduction: I prefer the abstract form of /date but not a time/date wi= thout a time/ I agree and will make this change in the next published draft. * While this is something that is clear to me, I got a recent comment when = I suggested that this be used elsewhere of, "But how does this work with ti= me zones?". Based on that I think that there needs to be some text about w= hy time zones are not of interest here. Agreed and will do. * Section 3- I think that the second paragraph would be wise to distinguish= between a point in time and a date when looking at access control decision= s. I understand your point in general. Is there particular text that you'd su= ggest that I incorporate? Jim Thanks again, -- Mike From nobody Mon Jun 15 00:44:46 2020 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 6267E3A0A8B for ; Mon, 15 Jun 2020 00:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO_3POa8qRAE for ; Mon, 15 Jun 2020 00:44:43 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60081.outbound.protection.outlook.com [40.107.6.81]) (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 8CFE03A0A8D for ; Mon, 15 Jun 2020 00:44:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=huxyHz7hmLq+PXSNx2Q1rahqlyRdh+ERldsRtSBhxco1eWyil+3JuYRzQPCAeJ+1PUDgbeUwBPtJpMhcOZ1iDrJO/vmPEBcxMbJBGaeZcUZBxfW5b9JJDlftyik3aDeOCn5PoFfQm5zv8mC1Oiq1JM7xq7+IpsOT2NFxQ+a/OanScYZ6hmKAB3pEbdvu8HsW9TzWBbXcNV1M/bwzoFJCXjnSJINKL6XfENKCZ61rlXl0Ahggr6eiJJPq/CV8m3cl9d9WOYThLKpkB7NcVSlYMWacd9npFokTMhCfGwS42hdwnSb3+CScEqu0i3Zf06tgnzIXZJpdpju2Kt3IHaE4aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qATn/vpNzGC/L3fsgS2/uTe/n80x52XJSNHf4wMeS5g=; b=IzCOikryB/N4/oY2g3wzLjetgwmbu72spj4/7ToPcq+c0yRWCW87rNypWzlI0bm79bOl9l9z8RSKARy+B1bFvxaPjoHwUUXg+5AvDHTaCu5fFjaGZ7g+0BtWfyAODNOw4CBpVh5abD3PkHkEWemPguHraU22RaPI6AS3guSRoYXCgNPwtx12nGjxTFsgzYMeL9vIuWHURrenPALpnldLf5D/2YVUJI7UI5ClJpogwJVNtLlfjQtDVUm9r14PiPbXUiGn9KKkSlH7py9LKs/7LTCrFG5vM656cVQ6m67QnUCbtn3BCV3aKREx9bKve+O0yEocD1V6xYHp2U9jAqs6RQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qATn/vpNzGC/L3fsgS2/uTe/n80x52XJSNHf4wMeS5g=; b=dA5MtCqcKx9zzzraENXWBzEKXvrDRuV0Y/MpZ2UUHt/MW9jqyH7KZiEiQyIkeRuAbRarGuE1llq7K1jNGPbNRfYRPldhy9NR0SOyFMgd6Z6EISnP9DCxMQ0kjbILv9w8FW7zm9iUInunkp4VtX0b+StD0BoYX5PFNgrawJYR9FE= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3385.eurprd07.prod.outlook.com (2603:10a6:7:32::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.9; Mon, 15 Jun 2020 07:44:41 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3109.018; Mon, 15 Jun 2020 07:44:41 +0000 From: Francesca Palombini To: "cbor@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMQ==?= Thread-Index: AQHWQujTL2XmmM5/uEmAEEz6AbaT5Q== Date: Mon, 15 Jun 2020 07:44:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 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: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b2abf4b-d8ba-4c80-60ee-08d810fff67c x-ms-traffictypediagnostic: HE1PR07MB3385: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lyKxXR0fOHDD8CpHSgRa3wVU2hqIC9fyTCzfr+qMUbcxnkN8YbePmW7ZJpAY4jpF7ypw34TO7j3IgUYD+WVEbmij/yKOdBJvAN3J78+l1KiJGN9lFuNgTBEtfP6f3MtQpVtjMB12XDHDkYbnqXeneCoNqx4MezkZm1uoUlcT3mCbhDCDKzCS4JX0ZYu1j7CRxdsG2KZP14/uMupL0iY6faWQHlyOXCNr38VixDs31Tov75equ2hQoItu5djnS/8MHFPvvetItwt3jSLgVyGCcWVchFsu20159SBsBwgYgTGooghkiDCKhbPuiannsXAnOLxsKJ7IXS3rnTPCwlnSzVnxIcLMt70R9Mx4rxfE+b4ddNY2yBNo866RcVNJPnvNSKQwvUPNXLsiA/dMMleMqw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(966005)(8936002)(2616005)(36756003)(44832011)(478600001)(66574014)(86362001)(83380400001)(64756008)(2906002)(6512007)(71200400001)(66946007)(316002)(6916009)(66476007)(6486002)(76116006)(66556008)(6506007)(33656002)(26005)(186003)(5660300002)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HJ2Wo6gogrPLWu2OupDlXnBJs6ZfQkPith7UlUbolgq4xJLNMhgpHY7OgA/uNnzrb3d4V42tawZ/SouQr5PJMUN4SEceG7+HRYarU8Zx47EBo1fV9fCEU6BRjJ0bANzajdFrn9IvURB+Tq85wNUmYF88poHaaOEbm46nU7ZzGj9pCOVslPn6uk9SFS92RXmOXsy9co6B4QR5dq92hc1P2f/g3TlagsNH5cJSdUQk3WsljwtTBFhrfZzVJzJl2w2uFFYmWpyosXGqO+8Kjtmbq8jumlgRSmx/FkzEi1m7rj06ohOPNs71PRyhNZCdtMAkkwBMCjus0+leNiJMTifG8+yO9GXFedXE3ppEiNpKOJgQZp8MnLfjzSYaUL+YMxaFRKJANeaxudmgxkDM9YJdt9xhvidkCyN1AQM75YmX3TPYgW/CjkoiRXdrb/Nrm4wf3RBe6v5HsjIhZ5aQ1d9UBHlx1gafL6mIwSlqTMrPBA7yHJhjJdqrlp5rp/8ZC34f x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b2abf4b-d8ba-4c80-60ee-08d810fff67c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 07:44:40.9747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pOkr8+UuibP0XKpBZbLuUnMPYeiNJYj4V1dT3rO55AV+N6b4+B1rfk1vQNzYpYsEUtfULqDedUa1aNryay54xpIvf/GVqdwIqRkfvPya9L7pC/ZILTJnw0mv+VHJ1fgC X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3385 Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-date-tag-0?= =?utf-8?q?1?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 07:44:45 -0000 Q0JPUiB3ZywNCg0KVGhpcyBzdGFydHMgYSB0d28gd2Vla3MgV0cgbGFzdCBjYWxsIG9uIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDEgLCBlbmRp bmcgb24gKk1vbmRheSwgMjl0aCBKdW5lKi4gTm90ZSB0aGF0IHRoZSBJQU5BIHJlZ2lzdHJhdGlv bnMgaGF2ZSBhbHJlYWR5IGdvbmUgdGhyb3VnaCwgc2VlIGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fz c2lnbm1lbnRzL2Nib3ItdGFncy9jYm9yLXRhZ3MueGh0bWwgLg0KDQpQbGVhc2Ugc2VuZCBpbnB1 dHMgdG8gdGhlIG1haWxpbmcgbGlzdCB0aGF0IHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFu ZCBkbyBvciBkbyBub3QgZmVlbCBpdCBpcyByZWFkeSB0byBwcm9ncmVzcywgYWxvbmcgd2l0aCBh bnkgaXNzdWVzIHRoYXQgeW91IGJlbGlldmUgbmVlZCB0byBiZSBkZWFsdCB3aXRoLg0KDQpXZSB3 aWxsIGRpc2N1c3MgYW55IG9wZW4gaXNzdWVzIHdl4oCZdmUgZ290dGVuIGR1cmluZyB0aGUgaW50 ZXJpbSBtZWV0aW5nIHNjaGVkdWxlZCBmb3IgV2VkbmVzZGF5LCBKdWx5IDFzdC4NCg0KQ0JPUiBD aGFpcnMNCkppbSAmIEZyYW5jZXNjYQ0KDQrvu79PbiAxMC8wNi8yMDIwLCAwMDowMCwgIkNCT1Ig b24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGNib3ItYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KDQog ICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiBNYWludGVuYW5jZSBh bmQgRXh0ZW5zaW9ucyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIChDQk9SKSBUYWdzIGZv ciBEYXRlDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBNaWNoYWVsIEIuIEpvbmVzDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbnRob255IE5hZGFsaW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIErDtnJnIFJpY2h0ZXINCiAgICAJRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAxLnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiA1 DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMjAtMDYtMDkNCg0KICAgIEFic3RyYWN0Og0KICAg ICAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IsIFJGQyA3 MDQ5KSBpcyBhIGRhdGENCiAgICAgICBmb3JtYXQgd2hvc2UgZGVzaWduIGdvYWxzIGluY2x1ZGUg dGhlIHBvc3NpYmlsaXR5IG9mIGV4dHJlbWVseSBzbWFsbA0KICAgICAgIGNvZGUgc2l6ZSwgZmFp cmx5IHNtYWxsIG1lc3NhZ2Ugc2l6ZSwgYW5kIGV4dGVuc2liaWxpdHkgd2l0aG91dCB0aGUNCiAg ICAgICBuZWVkIGZvciB2ZXJzaW9uIG5lZ290aWF0aW9uLg0KDQogICAgICAgSW4gQ0JPUiwgb25l IHBvaW50IG9mIGV4dGVuc2liaWxpdHkgaXMgdGhlIGRlZmluaXRpb24gb2YgQ0JPUiB0YWdzLg0K ICAgICAgIFJGQyA3MDQ5IGRlZmluZXMgdHdvIHRhZ3MgZm9yIHRpbWU6IENCT1IgdGFnIDAgKFJG QyAzMzM5IGRhdGUvdGltZQ0KICAgICAgIHN0cmluZykgYW5kIHRhZyAxIChQb3NpeCAic2Vjb25k cyBzaW5jZSB0aGUgZXBvY2giKS4gIFNpbmNlIHRoZW4sDQogICAgICAgYWRkaXRpb25hbCByZXF1 aXJlbWVudHMgaGF2ZSBiZWNvbWUga25vd24uICBUaGlzIHNwZWNpZmljYXRpb24NCiAgICAgICBk ZWZpbmVzIGEgQ0JPUiB0YWcgZm9yIGFuIFJGQyAzMzM5IGRhdGUgdGV4dCBzdHJpbmcsIGZvciBh cHBsaWNhdGlvbnMNCiAgICAgICBuZWVkaW5nIGEgdGV4dHVhbCBkYXRlIHJlcHJlc2VudGF0aW9u IHdpdGhvdXQgYSB0aW1lLiAgSXQgYWxzbw0KICAgICAgIGRlZmluZXMgYSBDQk9SIHRhZyBmb3Ig ZGF5cyBzaW5jZSB0aGUgUG9zaXggZXBvY2gsIGZvciBhcHBsaWNhdGlvbnMNCiAgICAgICBuZWVk aW5nIGEgbnVtZXJpYyBkYXRlIHJlcHJlc2VudGF0aW9uIHdpdGhvdXQgYSB0aW1lLiAgSXQgaXMg aW50ZW5kZWQNCiAgICAgICBhcyB0aGUgcmVmZXJlbmNlIGRvY3VtZW50IGZvciB0aGUgSUFOQSBy ZWdpc3RyYXRpb24gb2YgdGhlIENCT1IgdGFncw0KICAgICAgIGRlZmluZWQuDQoNCg0KICAgIFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy8N Cg0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAx DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNi b3ItZGF0ZS10YWctMDENCg0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAxDQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAg ICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQoNCg== From nobody Mon Jun 15 05:09:14 2020 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 B5E443A0D1D for ; Mon, 15 Jun 2020 05:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYug5Y7mB31X for ; Mon, 15 Jun 2020 05:09:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8EF3A0D1E for ; Mon, 15 Jun 2020 05:09:10 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49lqr41f4MzySb; Mon, 15 Jun 2020 14:09:08 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 613915747.7146831-03bba2b0741139ec06275968cced7bde Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 14:09:07 +0200 Message-Id: To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] New control operators for CDDL X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 12:09:13 -0000 I have submitted draft-bormann-cbor-cddl-control-00 with proposals for = five new control operators: * .cat and .plus for very basic computed literals (all that we seem to = need right now) * .abnf and .abnfb for ABNF in CDDL * .feature for keeping track of extension point usage by an instance in = validation (as already used in recent work on SDF). Title: Additional Control Operators for CDDL Document date: 2020-06-15 Group: Individual Submission Pages: 9 URL: = https://www.ietf.org/internet-drafts/draft-bormann-cbor-cddl-control-00.tx= t Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-control/ Html: = https://www.ietf.org/id/draft-bormann-cbor-cddl-control-00.html I have also updated draft-bormann-cbor-cddl-freezer to remove those = ideas from the freezer that are now represented in these five new = controls. .feature is provisionally implemented in the CDDL tool version 0.8.11; = the other four are waiting for the next version of the CDDL tool. Maybe we can talk about these on Wednesday. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 15 18:20:20 2020 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 A63303A0F72 for ; Mon, 15 Jun 2020 18:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k17q4atZBydP for ; Mon, 15 Jun 2020 18:20:11 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650114.outbound.protection.outlook.com [40.107.65.114]) (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 B912B3A0F82 for ; Mon, 15 Jun 2020 18:20:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XA1/MbPymvJg4m6xpGaUdPPa0BXk6vdu7EDzgMsxgyaI0dMocYNs/R0Y9EbvL7u1Q2UlsYoGRQo28kJaHRAD4cHt+aY3MV/AzR0Yha+tk3G3IhLYqZjDuFi8BUu+hueNQLkCgx1Xfx8m2aQFhzNU7XTRCVn7LMbxFhaBI7KnSYr3rVz8biMSmE7z/QvnJVLHYu+v9suSnKbDxG2LFhuG2pPVP3WBd4knA6L6krGFZS0D4WXRl5eqWCbwSUB53WrZwaOhlNYfONz20AtjDoXdBsitXPx6M7WoFfgfua2co6pdRlAWtWKVm46Q5tV4YZ9b+vnYXfSasN3HdofaidCMkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1+oRN8vNiWyWtOmwyF1YWhFbtJNSaHOwe9d8OHzYF8A=; b=Zlk4qtp7IK2ntryCpY7NIXSYj51KmqB+GnIM3vadRj4a0Z6EHOubo2WIpKGy2AO1RaieIQqyhtYEVYL7TQRzl81Be0ZGZ8s49Uj7rdZCGsiQiWAiB6kFh7ts8rawH8lVxSvnn7ZkuA01xgs3MTPv4fmnzQgan4LEKzBHaAXtWm1pL9K6C++YHEktMrzFuRqkFm3BjfPIxyHwkHDb4W0S+FPBluEvf/Po75QYZTbAxOiYuSXmyFbivIDNri4edYQP0lmgq4gctsWlqwA38YtqmerJ/YKXZiNZyX5+13JDCr1YiwmSLDv8yl0HlRy9epth+lk65vccSD6US7sjaop4Rg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1+oRN8vNiWyWtOmwyF1YWhFbtJNSaHOwe9d8OHzYF8A=; b=hLYGJo1yDUalzYf+exkQT07aL8FKAcCB+iRvKiDBNPOliW317K8++E0q9vpe8zIWEwqPaxTHYwU0Ud84y3JxdTYIJvZWaTGtKrni6tZq/UYgBGopRK7Ycoykugg9arw2EfS39E7O6g/wi2jSgxt9e2sM8guaI1eUFD0tw9aV6N4= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0755.namprd00.prod.outlook.com (2603:10b6:208:1c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3142.0; Tue, 16 Jun 2020 01:20:09 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02%9]) with mapi id 15.20.3145.000; Tue, 16 Jun 2020 01:20:09 +0000 From: Mike Jones To: Francesca Palombini , "cbor@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMQ==?= Thread-Index: AQHWQujTL2XmmM5/uEmAEEz6AbaT5ajacgtQ Date: Tue, 16 Jun 2020 01:20:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4a65d82c-0693-4839-bd8e-9064e76b5726; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-16T01:17:42Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0ae9ac72-5e66-4ec9-e697-08d811936956 x-ms-traffictypediagnostic: BL0PR00MB0755: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GykgJnYRT7zIUtycusOS7/3JmByhnQPm00fRTofYNAO9rc1ozxJGDrQBlPAEKYFlxmEyFFAAb/tw0k3+bG/dtjMgQ2+HBwoXmZ7/DSSvBff2LJOdwb08rEwzUz2F3tmPogTv05QmJ+pitlAM5TD58H+OJCpAIR4+TiMCM+GMWApcDfAw9yCib5yZUME5wFRgc4q25mUtKsMV7DRr/Nh9qFrd7gknatEUiwJ/9bXS8YElk1454QRJfjA4y4DfrCESSRek6QopQOghPniB7YY7ejeaOzGufVgIu2ccAa7Ov9NnMvxCpyyWHsy/ZQPtGSwyomeTM9xS7wLNDmkS05nvjcgezvB/MY04n8RtIGU/ax3IzqTF7kb8ABJprHwdewXKK0GD6Yvs0wv3Sb5CU91bUg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(376002)(39860400002)(136003)(346002)(966005)(82950400001)(110136005)(82960400001)(8990500004)(55016002)(76116006)(66556008)(66446008)(64756008)(66946007)(66476007)(26005)(66574015)(8936002)(83380400001)(9686003)(316002)(7696005)(10290500003)(2906002)(33656002)(6506007)(478600001)(52536014)(53546011)(71200400001)(86362001)(5660300002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: KdB4qKKCZ4XwkRf47KFljbDyLxKaURezVUi3xTJtdHJRD+KtlrDaUy/YqzlpRiYG6bCxezj/BJ7A6EzOws/qxfXiz6mEYHISKkP2hVK8d0llZUWwgxc7uwxkKdJoZ96DCYGk7MOxRqZUVz66hC5UepfwHc1AB1qT3aJ7zZVso6K46K/tTL0cRwCkVRE3S0hPaTFDSnI1kehGR7IdQ/rAzwnSi5diipz4j7SssGLjjhnn106MMWFOTSJUF7smrexrUYXw0Eh6Wf2whH6J9BvLSCx7apxEKyanjvlaUCoLUPpcan1+hroPvYtTEfIeGSsRBvNTB8fycOEqfnlNriixecbHZ4ARlGgg7FKOEK4CIMeq6LDV/f+MUrCqjzNq0CHxXe8e0YPrkBxgWs0RdxU38q0dbC9XB95OuxNJZnTThS9u1sWcKYRWvfAswjGMJPsSFXURM2koPci2xlAnfZ8rq5J7bLphZuYtLrT/JrEgUG0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ae9ac72-5e66-4ec9-e697-08d811936956 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 01:20:09.6519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Fw/VlI+yH6OVIm2QUtj2AnAF5Xh5aIZM9eqjrKP4O1to9mUlOMcXcyblZB0wu3OIgHVtYbJEGagEDGKLkiHCoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0755 Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-date-tag-0?= =?utf-8?q?1?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 01:20:18 -0000 SSBiZWxpZXZlIHRoYXQgdGhpcyAodmVyeSBzaG9ydCEpIHNwZWNpZmljYXRpb24gaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLiAgSSBwbGFuIHRvIGluY29ycG9yYXRlIEppbSdzIHN1Z2dlc3Rpb25z IGF0IHRoZSBzYW1lIHRpbWUgYXMgV0dMQyBjb21tZW50cyB0aGF0IGNvbWUgaW4uDQoNCgkJCQkt LSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDQk9SIDxjYm9yLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBGcmFuY2VzY2EgUGFsb21iaW5pDQpTZW50OiBN b25kYXksIEp1bmUgMTUsIDIwMjAgMTI6NDUgQU0NClRvOiBjYm9yQGlldGYub3JnDQpTdWJqZWN0 OiBbQ2Jvcl0g8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMQ0KDQpDQk9S IHdnLA0KDQpUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrcyBXRyBsYXN0IGNhbGwgb24gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMSAsIGVuZGluZyBv biAqTW9uZGF5LCAyOXRoIEp1bmUqLiBOb3RlIHRoYXQgdGhlIElBTkEgcmVnaXN0cmF0aW9ucyBo YXZlIGFscmVhZHkgZ29uZSB0aHJvdWdoLCBzZWUgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvY2Jvci10YWdzL2Nib3ItdGFncy54aHRtbCAuDQoNClBsZWFzZSBzZW5kIGlucHV0cyB0 byB0aGUgbWFpbGluZyBsaXN0IHRoYXQgeW91IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIGRv IG9yIGRvIG5vdCBmZWVsIGl0IGlzIHJlYWR5IHRvIHByb2dyZXNzLCBhbG9uZyB3aXRoIGFueSBp c3N1ZXMgdGhhdCB5b3UgYmVsaWV2ZSBuZWVkIHRvIGJlIGRlYWx0IHdpdGguDQoNCldlIHdpbGwg ZGlzY3VzcyBhbnkgb3BlbiBpc3N1ZXMgd2XigJl2ZSBnb3R0ZW4gZHVyaW5nIHRoZSBpbnRlcmlt IG1lZXRpbmcgc2NoZWR1bGVkIGZvciBXZWRuZXNkYXksIEp1bHkgMXN0Lg0KDQpDQk9SIENoYWly cw0KSmltICYgRnJhbmNlc2NhDQoNCu+7v09uIDEwLzA2LzIwMjAsIDAwOjAwLCAiQ0JPUiBvbiBi ZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8Y2Jvci1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCiAgICBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIE1haW50ZW5hbmNlIGFuZCBF eHRlbnNpb25zIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgICAgICBUaXRsZSAgICAgICAgICAg OiBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIFRhZ3MgZm9yIERh dGUNCiAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1pY2hhZWwgQi4gSm9uZXMNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFudGhvbnkgTmFkYWxpbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSsO2cmcgUmljaHRlcg0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWNib3ItZGF0ZS10YWctMDEudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDUNCiAg ICAJRGF0ZSAgICAgICAgICAgIDogMjAyMC0wNi0wOQ0KDQogICAgQWJzdHJhY3Q6DQogICAgICAg VGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiAoQ0JPUiwgUkZDIDcwNDkp IGlzIGEgZGF0YQ0KICAgICAgIGZvcm1hdCB3aG9zZSBkZXNpZ24gZ29hbHMgaW5jbHVkZSB0aGUg cG9zc2liaWxpdHkgb2YgZXh0cmVtZWx5IHNtYWxsDQogICAgICAgY29kZSBzaXplLCBmYWlybHkg c21hbGwgbWVzc2FnZSBzaXplLCBhbmQgZXh0ZW5zaWJpbGl0eSB3aXRob3V0IHRoZQ0KICAgICAg IG5lZWQgZm9yIHZlcnNpb24gbmVnb3RpYXRpb24uDQoNCiAgICAgICBJbiBDQk9SLCBvbmUgcG9p bnQgb2YgZXh0ZW5zaWJpbGl0eSBpcyB0aGUgZGVmaW5pdGlvbiBvZiBDQk9SIHRhZ3MuDQogICAg ICAgUkZDIDcwNDkgZGVmaW5lcyB0d28gdGFncyBmb3IgdGltZTogQ0JPUiB0YWcgMCAoUkZDIDMz MzkgZGF0ZS90aW1lDQogICAgICAgc3RyaW5nKSBhbmQgdGFnIDEgKFBvc2l4ICJzZWNvbmRzIHNp bmNlIHRoZSBlcG9jaCIpLiAgU2luY2UgdGhlbiwNCiAgICAgICBhZGRpdGlvbmFsIHJlcXVpcmVt ZW50cyBoYXZlIGJlY29tZSBrbm93bi4gIFRoaXMgc3BlY2lmaWNhdGlvbg0KICAgICAgIGRlZmlu ZXMgYSBDQk9SIHRhZyBmb3IgYW4gUkZDIDMzMzkgZGF0ZSB0ZXh0IHN0cmluZywgZm9yIGFwcGxp Y2F0aW9ucw0KICAgICAgIG5lZWRpbmcgYSB0ZXh0dWFsIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0 aG91dCBhIHRpbWUuICBJdCBhbHNvDQogICAgICAgZGVmaW5lcyBhIENCT1IgdGFnIGZvciBkYXlz IHNpbmNlIHRoZSBQb3NpeCBlcG9jaCwgZm9yIGFwcGxpY2F0aW9ucw0KICAgICAgIG5lZWRpbmcg YSBudW1lcmljIGRhdGUgcmVwcmVzZW50YXRpb24gd2l0aG91dCBhIHRpbWUuICBJdCBpcyBpbnRl bmRlZA0KICAgICAgIGFzIHRoZSByZWZlcmVuY2UgZG9jdW1lbnQgZm9yIHRoZSBJQU5BIHJlZ2lz dHJhdGlvbiBvZiB0aGUgQ0JPUiB0YWdzDQogICAgICAgZGVmaW5lZC4NCg0KDQogICAgVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLw0KDQog ICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNib3ItZGF0ZS10YWctMDENCiAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wMQ0KDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWNib3ItZGF0ZS10YWctMDENCg0KDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkNCT1IgbWFpbGluZyBsaXN0DQpDQk9SQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg== From nobody Tue Jun 16 12:37:33 2020 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 DB9673A132A; Tue, 16 Jun 2020 12:37:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159233624382.1793.11522325746607837754@ietfa.amsl.com> Date: Tue, 16 Jun 2020 12:37:23 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-06-17 CHANGED X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 19:37:24 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) WG will hold a virtual interim meeting on 2020-06-17 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: CBOR WG Meeting - Interim 20-11 Wednesday, June 17, 2020, 17:00 - 18:00 CEST Chairs: Francesca Palombini, Jim Schaad Webex: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 Jabber: cbor@jabber.ietf.org Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-cbor-11-cbor?useMonospaceFont=true Agenda: * CBOR Tag for Date status : chairs https://tools.ietf.org/html/draft-jones-cbor-date-tag-01 * CBOR specification status : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 https://github.com/cbor-wg/CBORbis/ * New control operators for CDDL: Carsten https://tools.ietf.org/html/draft-bormann-cbor-cddl-control-00 * AoB Information about remote participation: Webex: https://ietf.webex.com/ietf/j.php?MTID=m5db53ad850244e25fcecf10c30a1a811 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 From nobody Tue Jun 16 14:25:45 2020 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 9C1FE3A07A9; Tue, 16 Jun 2020 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9YYvG1t9RL7; Tue, 16 Jun 2020 14:25:42 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B493A0798; Tue, 16 Jun 2020 14:25:39 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jun 2020 14:25:33 -0700 From: Jim Schaad To: CC: Date: Tue, 16 Jun 2020 14:25:31 -0700 Message-ID: <010101d64424$abeb6310$03c22930$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZEG37k2vsvz62cTTe3JgILQK7Qww== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] Review of draft-bormann-cbor-cddl-control-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 21:25:44 -0000 * 2.1 - para 3 - I think you can state this easier as "Target can controller MUST be strings. The result of the operation has the type of the target. The concatenation is performed on the bytes in both strings." * 2.1 - para 3 - I just did a really fast search on CDDL and I am not sure that it states anyplace that strings are treated as UTF-8. I think this is probably implicit but saying you are doing the concatenation on the bytes has the potential to cause a problem. * 2.2 - para 2 - The rule for dealing w/ mixed floating point and integer is ambiguous. This is not a good idea. It would seem that an equally valid interpretation is to use ceiling rather than floor. * 3 - nit s/can directly be added/are added/ * 3 - need to have some rules on the controls, targets and controller in terms of types. Can I use .abnf with a binary target and controller? * 3 - I assume that there is an implicit rule that the ABNF must be validated and the CDDL is invalid if it is not valid. * 4 - I need a much more detailed explanation of what this control is supposed to be doing. * 4 - I find the following very hard to parse: Extensions that are known at the time this definition is known Jim From nobody Tue Jun 16 16:54:39 2020 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 7A2313A0AC3; Tue, 16 Jun 2020 16:54:37 -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: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159235167742.14893.8397403111361055052@ietfa.amsl.com> Date: Tue, 16 Jun 2020 16:54:37 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-7049bis-14.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 23:54:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Authors : Carsten Bormann Paul Hoffman Filename : draft-ietf-cbor-7049bis-14.txt Pages : 76 Date : 2020-06-16 Abstract: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-7049bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-7049bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 16 17:08:37 2020 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 8D6873A0B4A for ; Tue, 16 Jun 2020 17:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLs2xNi5aAy4 for ; Tue, 16 Jun 2020 17:08:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB2A3A0B40 for ; Tue, 16 Jun 2020 17:08:32 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49mllY04MDzydV; Wed, 17 Jun 2020 02:08:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann Date: Wed, 17 Jun 2020 02:08:24 +0200 X-Mao-Original-Outgoing-Id: 614045304.496966-2a279340b92b5e79730051fa7cac4dc1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <159235167770.14893.3369403046169290859@ietfa.amsl.com> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Fwd: New Version Notification for draft-ietf-cbor-7049bis-14.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 00:08:37 -0000 7049bis-14 closes all remaining known issues. I moved Appendix F =E2=80=9CChanges from RFC 7049=E2=80=9D behind the = well-formed errors (so it is now Appendix G) and filled in text about = all the changes I could find. So please do have a look at that = appendix, it is mostly text you haven=E2=80=99t seen yet, in particular = G.3: = https://www.ietf.org/id/draft-ietf-cbor-7049bis-14.html#name-changes-from-= rfc-7049 Assuming the shepherd report goes well, this should bring us close to = IESG submission. Gr=C3=BC=C3=9Fe, Carsten > Name: draft-ietf-cbor-7049bis > Revision: 14 > Title: Concise Binary Object Representation (CBOR) > Document date: 2020-06-17 > Group: cbor > Pages: 76 > Status: = https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ > Html: = https://www.ietf.org/id/draft-ietf-cbor-7049bis-14.html > Htmlized: https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-7049bis-14 From nobody Tue Jun 16 18:10:03 2020 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 8765C3A0D72; Tue, 16 Jun 2020 18:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3izhfQKPWEh8; Tue, 16 Jun 2020 18:09:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6DD3A0D46; Tue, 16 Jun 2020 18:09:48 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49mn6L22FKzydL; Wed, 17 Jun 2020 03:09:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <010101d64424$abeb6310$03c22930$@augustcellars.com> Date: Wed, 17 Jun 2020 03:09:45 +0200 Cc: draft-bormann-cbor-cddl-control@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 614048985.7906131-889ab39357ced50e1627d5df4370c5b2 Content-Transfer-Encoding: quoted-printable Message-Id: <648B2C8B-5F4D-4550-95BB-593C5D3F74E7@tzi.org> References: <010101d64424$abeb6310$03c22930$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review of draft-bormann-cbor-cddl-control-00 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 01:10:02 -0000 Hi Jim, thank you for your fast review! On 2020-06-16, at 23:25, Jim Schaad wrote: >=20 > * 2.1 - para 3 - I think you can state this easier as "Target can = controller > MUST be strings. The result of the operation has the type of the = target. > The concatenation is performed on the bytes in both strings." Done, thanks. > * 2.1 - para 3 - I just did a really fast search on CDDL and I am not = sure > that it states anyplace that strings are treated as UTF-8. I think = this is > probably implicit but saying you are doing the concatenation on the = bytes > has the potential to cause a problem. Added "If the target is a text string, the result of that concatenation = MUST be valid UTF-8." > * 2.2 - para 2 - The rule for dealing w/ mixed floating point and = integer is > ambiguous. This is not a good idea. It would seem that an equally = valid > interpretation is to use ceiling rather than floor. Fixed. > * 3 - nit s/can directly be added/are added/ Done (is). > * 3 - need to have some rules on the controls, targets and controller = in > terms of types. Can I use .abnf with a binary target and controller? =20= I added some text: > * 3 - I assume that there is an implicit rule that the ABNF must be > validated and the CDDL is invalid if it is not valid. Well, we never exactly specified what =E2=80=9Cvalid=E2=80=9D means for = ABNF. If you mean that a tool should throw an error upon encountering a = controller string that is not =E2=80=9Celement CRLF *rule=E2=80=9D. > * 4 - I need a much more detailed explanation of what this control is > supposed to be doing. =20 I added one more way to further muddy the waters (but also adding = explanation). > * 4 - I find the following very hard to parse: Extensions that are = known at > the time this definition is known Fixed (I think). Thanks again; I have submitted the update as -01. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 16 22:42:47 2020 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 593383A0ECF; Tue, 16 Jun 2020 22:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNVCR1xRT9-w; Tue, 16 Jun 2020 22:42:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EFA3A0ED1; Tue, 16 Jun 2020 22:42:42 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49mv9D5FLSzyZc; Wed, 17 Jun 2020 07:42:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 17 Jun 2020 07:42:40 +0200 Cc: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 614065360.228742-8edddc27eedd8c30779c32b1972716b3 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Jones X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 05:42:46 -0000 I sent some nits from a quick review of -01 to the authors. The one item that will need a little more work: I also agree with Jim that we need to say something about the = timezone-lessness of the two tags. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 17 09:34:45 2020 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 008653A0A6C; Wed, 17 Jun 2020 09:34:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Cc: cbor@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, iesg-secretary@ietf.org, Francesca Palombini Message-ID: <159241168298.28972.9389066920289636303@ietfa.amsl.com> Date: Wed, 17 Jun 2020 09:34:42 -0700 Archived-At: Subject: [Cbor] Publication has been requested for draft-ietf-cbor-7049bis-14 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:34:43 -0000 Francesca Palombini has requested publication of draft-ietf-cbor-7049bis-14 as Internet Standard on behalf of the CBOR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/ From nobody Wed Jun 17 09:36:26 2020 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 C9F0A3A0AAB for ; Wed, 17 Jun 2020 09:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159241177181.28940.15529637561950792830@ietfa.amsl.com> Date: Wed, 17 Jun 2020 09:36:11 -0700 From: IETF Secretariat Archived-At: Subject: [Cbor] Milestones changed for cbor WG X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:36:23 -0000 Changed milestone "Submit rfc7049bis to IESG as a Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/cbor/about/ From nobody Wed Jun 24 17:17:50 2020 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 989433A11F0 for ; Wed, 24 Jun 2020 17:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eft5oBhQ9pOQ for ; Wed, 24 Jun 2020 17:17:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5253A11EE for ; Wed, 24 Jun 2020 17:17:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Jun 2020 17:17:40 -0700 From: Jim Schaad To: References: In-Reply-To: Date: Wed, 24 Jun 2020 17:17:39 -0700 Message-ID: <01aa01d64a86$0ae8cb70$20ba6250$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQHDHmqOdrSYKAkYfpzrJUzHY6OBBqkOzxvQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-date-tag-0?= =?utf-8?q?1?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 00:17:49 -0000 Hey people, I would really like to see a couple of more comments from = people even if it is just - yeah looks good to me. Jim > -----Original Message----- > From: CBOR On Behalf Of Francesca Palombini > Sent: Monday, June 15, 2020 12:45 AM > To: cbor@ietf.org > Subject: [Cbor] =F0=9F=94=94 WGLC on draft-ietf-cbor-date-tag-01 >=20 > CBOR wg, >=20 > This starts a two weeks WG last call on = https://tools.ietf.org/html/draft-ietf- > cbor-date-tag-01 , ending on *Monday, 29th June*. Note that the IANA > registrations have already gone through, see > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml . >=20 > Please send inputs to the mailing list that you have read the document = and do > or do not feel it is ready to progress, along with any issues that you = believe > need to be dealt with. >=20 > We will discuss any open issues we=E2=80=99ve gotten during the = interim meeting > scheduled for Wednesday, July 1st. >=20 > CBOR Chairs > Jim & Francesca >=20 > =EF=BB=BFOn 10/06/2020, 00:00, "CBOR on behalf of = internet-drafts@ietf.org" bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Concise Binary Object = Representation > Maintenance and Extensions WG of the IETF. >=20 > Title : Concise Binary Object Representation = (CBOR) Tags for Date > Authors : Michael B. Jones > Anthony Nadalin > J=C3=B6rg Richter > Filename : draft-ietf-cbor-date-tag-01.txt > Pages : 5 > Date : 2020-06-09 >=20 > Abstract: > The Concise Binary Object Representation (CBOR, RFC 7049) is a = data > format whose design goals include the possibility of extremely = small > code size, fairly small message size, and extensibility without = the > need for version negotiation. >=20 > In CBOR, one point of extensibility is the definition of CBOR = tags. > RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 = date/time > string) and tag 1 (Posix "seconds since the epoch"). Since = then, > additional requirements have become known. This specification > defines a CBOR tag for an RFC 3339 date text string, for = applications > needing a textual date representation without a time. It also > defines a CBOR tag for days since the Posix epoch, for = applications > needing a numeric date representation without a time. It is = intended > as the reference document for the IANA registration of the CBOR = tags > defined. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cbor-date-tag-01 > https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-date-tag-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Wed Jun 24 18:28:21 2020 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 C6B413A1222 for ; Wed, 24 Jun 2020 18:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKliTKaV9TGy for ; Wed, 24 Jun 2020 18:28:18 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 B0EB73A121D for ; Wed, 24 Jun 2020 18:28:18 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id oGbMjrIyVFhrKoGgbjCnEw; Thu, 25 Jun 2020 01:28:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1593048497; bh=ZLP6rtfNP+O+pdykdhdmaV1yXQqQXInG1jXrX46xlII=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GGoe5hACN0sWz2Pz9PEH20bU5JLgEOP/I2JuKmYALPJ2uBCOfzcmYRWccoE1MdVee E5xG+ZaTVaur9TOcsNHccuy2YNkUOCznp2IDqpNOqqhDnZyYPAYdcF8U26lTIVX8mf g9t8V+yZtFyz/k+6mwz2ubv/IUxOFkwE3RaUgqqUyXxL3Ss6BiPtqspBjJ80cOlpqn oAXzhU93f1Z86mLuWD22WsDrLEzZ2NMP3GDWguHMPRQubSjTB4SW/zcV4S76H74aRP MjyvGOjZtGd/XAddF4oBHpSHVEYSCvgCqSuJWJ7IKWVjg0gacVcd3bEQ3VqYoYTus+ FU5bPmZUHb/XA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-12v.sys.comcast.net with ESMTPA id oGgZj6xQyQ3uSoGgajZ8ik; Thu, 25 Jun 2020 01:28:16 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 05P1SF1G008768; Wed, 24 Jun 2020 21:28:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 05P1SEq8008765; Wed, 24 Jun 2020 21:28:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Jim Schaad Cc: cbor@ietf.org In-Reply-To: <01aa01d64a86$0ae8cb70$20ba6250$@augustcellars.com> (ietf@augustcellars.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 24 Jun 2020 21:28:14 -0400 Message-ID: <87eeq42att.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cbor] WGLC on draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 01:28:20 -0000 Jim Schaad writes: > Hey people, I would really like to see a couple of more comments from > people even if it is just - yeah looks good to me. Not that I'm an expert in time, but reviewing -01, I couldn't find any tricky ambiguity about leap seconds, which is where time formats usually fall down -- RFC 3339 specifies how leap seconds are to be designated, and when counting days, leap seconds are automatically included. Since tag numbers are not a limited resource, there's no need to worry whether this is the best possible way to encode these data. So it looks good to me. Dale From nobody Thu Jun 25 13:23:12 2020 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 5A4DA3A0FE8 for ; Thu, 25 Jun 2020 13:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaeJsWt01YFs for ; Thu, 25 Jun 2020 13:23:00 -0700 (PDT) Received: from p3plsmtpa11-03.prod.phx3.secureserver.net (p3plsmtpa11-03.prod.phx3.secureserver.net [68.178.252.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2B73A086C for ; Thu, 25 Jun 2020 13:23:00 -0700 (PDT) Received: from laurences-mbp.lan ([70.58.199.219]) by :SMTPAUTH: with ESMTPA id oYOajYrYdkqCwoYOejaMpn; Thu, 25 Jun 2020 13:22:59 -0700 X-CMAE-Analysis: v=2.3 cv=E9qzWpVl c=1 sm=1 tr=0 a=vYbQBYz1awqCo8DrEKtgEg==:117 a=vYbQBYz1awqCo8DrEKtgEg==:17 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=48vgC7mUAAAA:8 a=IFEPa7c5ERqnriFequQA:9 a=LQZE7DElRNvClLKm:21 a=xXpgfyITG_0ZeH4i:21 a=QEXdDO2ut3YA:10 a=c4f3AP4XBhhLCqgK0C8A:9 a=dSQX3kAPR0iFDm-b:21 a=xCrltX17RVKcpTZA:21 a=d3sozsNUA7ZGbxpe:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_262C15AD-0BA9-4960-A04B-DD0B45A4667A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 13:22:51 -0700 In-Reply-To: Cc: cbor@ietf.org To: Carsten Bormann References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfO5136TUwR04yfTkdkqvy/Uh+U/JZ9dyIvM6G6BDYxAWD0aUsYqsjpqzmvA8708lKlwSGyY3U9J7i4XgzsKRbFMzZjqsdVy1TeoA++qijX+6rWyj0pUx nc45evNERhYCnOzCfmBtv4fzZZNi1Rj8KAG6EQSF1TKntzaRq9J2kZe9T2WLrQJrj++rpxVCz0qDTg== Archived-At: Subject: [Cbor] Registering a standard tag for QCBOR sequences (was Re: tag 24, CBOR sequence and non-CBOR sequence) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 20:23:12 -0000 --Apple-Mail=_262C15AD-0BA9-4960-A04B-DD0B45A4667A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So we do need to register / assign a tag for bstr wrapped CBOR = sequences. I can=E2=80=99t complete the implementation I=E2=80=99m working on until = I know assigned tag number. We kind of have a (small) hole in CBOR = without the definition of this tag. It does seem like this should be a full standard tag since tag 24 is a = full standard tag, so maybe tag 20? Seems the obvious place to do it is = in CBORbis, if it=E2=80=99s not too late. LL > On Jun 11, 2020, at 12:43 PM, Laurence Lundblade = wrote: >=20 > Hi Carsten, >=20 > One could say CBOR protocol world is bifurcated into sequence = protocols and single-item protocols, but it=E2=80=99s more complex than = that because a CBOR protocol that has both could be defined. And there = is the 55799 tag which allows either a sequence or single item.=20 >=20 > To be abundantly clear, I=E2=80=99m tempted to write of this in CBOR = protocol design considerations. >=20 > Was thinking that COSE payload was similar to 55799 in allowing both, = but it is actually another thing entirely. It is not tag 24 or any other = tag. It uses the MIME / COAP typing system which can indicate CBOR or = CBOR sequence or name some other protocol that then in turn indicates = which. >=20 > I don=E2=80=99t know what the advantage of this variability and = complexity is. Wouldn=E2=80=99t be simpler for the CBOR world if = sequences were the only thing? They are a super-set of single items. The = only thing I can think of is that this complexity allows some decoders = to be a little simpler by omitting support for sequences. >=20 > But, it seems the main reason is that no one thought about this in = detail until recently (me included; in theory I should have about four = years ago when I started on QCBOR :-) ) >=20 >=20 > What do you think of this as a way forward to reduce the complexity a = little?=20 >=20 > Define a new standard tag alternate to tag 24 the content of which is = a sequence (as planned). >=20 > A CBOR sequence is always able to carry a single item, therefore = encourage use of this new tag and the MIME and COAP types for sequences = over the ones for single items. >=20 > Encourage CBOR decoders to support sequences. >=20 > I don=E2=80=99t see these types and tags as part of the mechanism that = sets requirements for decoders implementing protocols. If you are going = to implement a CBOR protocol, you have to know if it is a single-item = protocol or sequence protocol and you have to select a CBOR decoder that = can handle the protocol. That decision is made when code is written, not = when a typed/tagged blob of CBOR arrives.=20 >=20 > Any implementation of a single-item protocol must deal with extra = bytes to do a good job. Just because something has tag 24 doesn=E2=80=99t = mean it won=E2=80=99t have some extra bytes (that might be CBOR), so the = tag doesn=E2=80=99t defend against or relieve the decoder of this work. >=20 > Agreed there is a backwards compatibility issue in allowing sequence = in tag 24, but it is only for decoders that explicitly check that there = is only a single item in the content of tag 24 in their very explicit = implementation of tag 24. If they just hand the contents of tag 24 to = the next level protocol decoder there would be no backwards = compatibility issue in practice. I suspect most implementations of tag = 24 don=E2=80=99t pre-check its contents before handing it off. =20 >=20 > I don=E2=80=99t want to implement tag 24 with that check for a single = item because it adds code and seems like code that is not particularly = necessary given the implementation of the decoding of the content will = pretty much have to perform that check too as part of the protocol = decoding it does. I will probably just treat tag 24 and the new sequence = tag the same way and allow sequences in either. I can=E2=80=99t see a = downside to doing that. >=20 > LL >=20 >=20 >> On Jun 7, 2020, at 11:22 AM, Carsten Bormann > wrote: >>=20 >> Hi Laurence. >>=20 >>>=20 >>> How about stating it like this? >>=20 >> We could, but stating for every encoded CBOR data item that it is not = intended to allow CBOR sequences with 0, 2, or more encoded CBOR data = items in them strikes me as confusing. >>=20 >> If I read a book about tomatoes, I would be confused if that states = again and again for some content that that does not apply to apples. >>=20 >>> While tag 24 can contain a sequence of length one, it cannot contain = most sequences as defined in 8742.=20 >>=20 >> Yes, and we can be abundantly clear about that, see PR #200. >> Without mentioning CBOR sequences. >>=20 >> [=E2=80=A6] >>> QCBOR is fine with sequences or not as input. >>=20 >> That is certainly a valid way to do things, but that should be made = obvious at the API. >>=20 >>> The CBOR playground doesn=E2=80=99t allow sequences. >>=20 >> Right, because it was written before we got a handle on how useful = sequences are as a separate concept. >>=20 >>> Personally, I still think it would be better to relax the = distinction and allow tag 24 to carry sequences rather than define a new = tag. >>=20 >> That would add some confusion between CBOR data items and CBOR = sequences, so for me that would be a change for the worse. >>=20 >>> It is a broadening, not a narrowing so it doesn=E2=80=99t break = anything. There=E2=80=99s no backwards compatibility issue just like = there was no backwards compatibility issue for 7049 when 8742 was = published.=20 >>=20 >> There is a backwards compatibility issue: Without the change, both = sides of the communication can rely to get what they expect =E2=80=94 = one CBOR data item. After the change, new implementations might start = to send two, and that kills backwards compatibility with old = implementations. >>=20 >>> If not relaxing the distinction and a new tag is defined for 8742, = maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as content = for tag 24. >>=20 >> It does so (and more so with #200), but not with these exact words. >>=20 >>> It is OK for CBORbis to make normative reference to 8742. >>=20 >> Actually, no (that would be a downref). But that did not stop us = from putting in informative references. I just don=E2=80=99t think we = need another one here; PR #200 is about as far as we want to go here = before we add confusion. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_262C15AD-0BA9-4960-A04B-DD0B45A4667A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So we do need to register / assign a tag for bstr wrapped = CBOR sequences.

I can=E2=80=99t complete the implementation I=E2=80=99m = working on until I know assigned tag number. We kind of have a (small) = hole in CBOR without the definition of this tag.

It does seem like this should be a full = standard tag since tag 24 is a full standard tag, so maybe tag 20? Seems = the obvious place to do it is in CBORbis, if it=E2=80=99s not too = late.

LL



On Jun 11, 2020, at 12:43 PM, Laurence Lundblade <lgl@island-resort.com> wrote:

Hi = Carsten,

One = could say CBOR protocol world is bifurcated into sequence protocols and = single-item protocols, but it=E2=80=99s more complex than that because a = CBOR protocol that has both could be defined. And there is the 55799 tag = which allows either a sequence or single item. 

To be abundantly clear, = I=E2=80=99m tempted to write of this in CBOR protocol design = considerations.

Was thinking that COSE payload was similar to 55799 in = allowing both, but it is actually another thing entirely. It is not tag = 24 or any other tag. It uses the MIME / COAP typing system which can = indicate CBOR or CBOR sequence or name some other protocol that then in = turn indicates which.

I don=E2=80=99t know what the advantage of this variability = and complexity is. Wouldn=E2=80=99t be simpler for the CBOR world if = sequences were the only thing? They are a super-set of single items. The = only thing I can think of is that this complexity allows some decoders = to be a little simpler by omitting support for sequences.

But, it seems the main = reason is that no one thought about this in detail until recently (me = included; in theory I should have about four years ago when I started on = QCBOR :-) )


What do you think of this as a way = forward to reduce the complexity a little? 

Define a new standard tag = alternate to tag 24 the content of which is a sequence (as = planned).

A = CBOR sequence is always able to carry a single item, therefore encourage = use of this new tag and the MIME and COAP types for sequences over the = ones for single items.

Encourage CBOR decoders to support = sequences.

I don=E2=80=99t see these types and tags as part of the = mechanism that sets requirements for decoders implementing protocols. If = you are going to implement a CBOR protocol, you have to know if it is a = single-item protocol or sequence protocol and you have to select a CBOR = decoder that can handle the protocol. That decision is made when code is = written, not when a typed/tagged blob of CBOR arrives. 

Any implementation of a = single-item protocol must deal with extra bytes to do a good job. Just = because something has tag 24 doesn=E2=80=99t mean it won=E2=80=99t have = some extra bytes (that might be CBOR), so the tag doesn=E2=80=99t defend = against or relieve the decoder of this work.

Agreed there is a backwards = compatibility issue in allowing sequence in tag 24, but it is only for = decoders that explicitly check that there is only a single item in the = content of tag 24 in their very explicit implementation of tag 24. If = they just hand the contents of tag 24 to the next level protocol decoder = there would be no backwards compatibility issue in practice.  I = suspect most implementations of tag 24 don=E2=80=99t pre-check its = contents before handing it off.  

I don=E2=80=99t want to implement tag = 24 with that check for a single item because it adds code and seems like = code that is not particularly necessary given the implementation of the = decoding of the content will pretty much have to perform that check too = as part of the protocol decoding it does. I will probably just treat tag = 24 and the new sequence tag the same way and allow sequences in either. = I can=E2=80=99t see a downside to doing that.

LL


On Jun 7, 2020, at 11:22 AM, Carsten Bormann <cabo@tzi.org> = wrote:

Hi Laurence.


How about stating it like = this?

We could, but stating = for every encoded CBOR data item that it is not intended to allow CBOR = sequences with 0, 2, or more encoded CBOR data items in them strikes me = as confusing.

If I read a book about = tomatoes, I would be confused if that states again and again for some = content that that does not apply to = apples.

While tag 24 can contain a sequence of length one, it cannot = contain most sequences as defined in 8742.
Yes, and we can be abundantly clear about that, see PR = #200.
Without mentioning CBOR sequences.

[=E2=80=A6]
QCBOR is fine with sequences or not as input.

That is certainly a valid way to = do things, but that should be made obvious at the API.

The CBOR playground = doesn=E2=80=99t allow sequences.

Right, because it was written before we got a handle on how = useful sequences are as a separate concept.

Personally, I still = think it would be better to relax the distinction and allow tag 24 to = carry sequences rather than define a new tag.

That would add some confusion = between CBOR data items and CBOR sequences, so for me that would be a = change for the worse.

It is a broadening, not a narrowing so it = doesn=E2=80=99t break anything. There=E2=80=99s no backwards = compatibility issue just like there was no backwards compatibility issue = for 7049 when 8742 was published.

There is a backwards compatibility issue: Without the change, = both sides of the communication can rely to get what they expect =E2=80=94= one CBOR data item.  After the change, new implementations might = start to send two, and that kills backwards compatibility with old = implementations.

If not relaxing the distinction and a new tag is defined for = 8742, maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as = content for tag 24.

It does so = (and more so with #200), but not with these exact words.
It is OK for CBORbis to = make normative reference to 8742.

Actually, no (that would be a downref).  But that did = not stop us from putting in informative references.  I just don=E2=80= =99t think we need another one here; PR #200 is about as far as we want = to go here before we add confusion.

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

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

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

= --Apple-Mail=_262C15AD-0BA9-4960-A04B-DD0B45A4667A-- From nobody Thu Jun 25 14:08:58 2020 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 4E3B73A101C for ; Thu, 25 Jun 2020 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPvzaDhenwdR for ; Thu, 25 Jun 2020 14:08:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B9A3A1019 for ; Thu, 25 Jun 2020 14:08:52 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49tCLC07SWzywK; Thu, 25 Jun 2020 23:08:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jun 2020 23:08:50 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 614812130.513658-4d088084761cc2b5980bb67ca9715d5d Content-Transfer-Encoding: quoted-printable Message-Id: <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Registering a standard tag for QCBOR sequences (was Re: tag 24, CBOR sequence and non-CBOR sequence) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 21:08:56 -0000 Hi Laurence, On 2020-06-25, at 22:22, Laurence Lundblade = wrote: > So we do need to register / assign a tag for bstr wrapped CBOR = sequences. Yes. > I can=E2=80=99t complete the implementation I=E2=80=99m working on = until I know assigned tag number. We kind of have a (small) hole in CBOR = without the definition of this tag. Yes. Fortunately, registering a tag is low-threshold. > It does seem like this should be a full standard tag since tag 24 is a = full standard tag, I don=E2=80=99t know what a full standard tag is. > so maybe tag 20? 20 is a 1+0 tag, of which only 12 are left. 24 is 1+1, so the equivalent for CBOR Sequences should have a 1+1 tag, = too. 63, the number we registered as a Content-Format ID for = application/cbor-seq, happens to be free, so I am proposing that we use = that as a tag number as well (we have achieved this little piece of = mnemonic economy before). > Seems the obvious place to do it is in CBORbis, if it=E2=80=99s not = too late. CBORbis is not intended to have additions to RFC 7049. We already solved this problem once (for the invalid tags) using the = notable-tags document. I published an update to notable-tags that specifies the new tag in=20 https://www.ietf.org/id/draft-bormann-cbor-notable-tags-02.html and, in the interest of expedience, went ahead and asked IANA to = register the tag. Gr=C3=BC=C3=9Fe, Carsten >> On Jun 11, 2020, at 12:43 PM, Laurence Lundblade = wrote: >>=20 >> Hi Carsten, >>=20 >> One could say CBOR protocol world is bifurcated into sequence = protocols and single-item protocols, but it=E2=80=99s more complex than = that because a CBOR protocol that has both could be defined. And there = is the 55799 tag which allows either a sequence or single item.=20 >>=20 >> To be abundantly clear, I=E2=80=99m tempted to write of this in CBOR = protocol design considerations. >>=20 >> Was thinking that COSE payload was similar to 55799 in allowing both, = but it is actually another thing entirely. It is not tag 24 or any other = tag. It uses the MIME / COAP typing system which can indicate CBOR or = CBOR sequence or name some other protocol that then in turn indicates = which. >>=20 >> I don=E2=80=99t know what the advantage of this variability and = complexity is. Wouldn=E2=80=99t be simpler for the CBOR world if = sequences were the only thing? They are a super-set of single items. The = only thing I can think of is that this complexity allows some decoders = to be a little simpler by omitting support for sequences. >>=20 >> But, it seems the main reason is that no one thought about this in = detail until recently (me included; in theory I should have about four = years ago when I started on QCBOR :-) ) >>=20 >>=20 >> What do you think of this as a way forward to reduce the complexity a = little?=20 >>=20 >> Define a new standard tag alternate to tag 24 the content of which is = a sequence (as planned). >>=20 >> A CBOR sequence is always able to carry a single item, therefore = encourage use of this new tag and the MIME and COAP types for sequences = over the ones for single items. >>=20 >> Encourage CBOR decoders to support sequences. >>=20 >> I don=E2=80=99t see these types and tags as part of the mechanism = that sets requirements for decoders implementing protocols. If you are = going to implement a CBOR protocol, you have to know if it is a = single-item protocol or sequence protocol and you have to select a CBOR = decoder that can handle the protocol. That decision is made when code is = written, not when a typed/tagged blob of CBOR arrives.=20 >>=20 >> Any implementation of a single-item protocol must deal with extra = bytes to do a good job. Just because something has tag 24 doesn=E2=80=99t = mean it won=E2=80=99t have some extra bytes (that might be CBOR), so the = tag doesn=E2=80=99t defend against or relieve the decoder of this work. >>=20 >> Agreed there is a backwards compatibility issue in allowing sequence = in tag 24, but it is only for decoders that explicitly check that there = is only a single item in the content of tag 24 in their very explicit = implementation of tag 24. If they just hand the contents of tag 24 to = the next level protocol decoder there would be no backwards = compatibility issue in practice. I suspect most implementations of tag = 24 don=E2=80=99t pre-check its contents before handing it off. =20 >>=20 >> I don=E2=80=99t want to implement tag 24 with that check for a single = item because it adds code and seems like code that is not particularly = necessary given the implementation of the decoding of the content will = pretty much have to perform that check too as part of the protocol = decoding it does. I will probably just treat tag 24 and the new sequence = tag the same way and allow sequences in either. I can=E2=80=99t see a = downside to doing that. >>=20 >> LL >>=20 >>=20 >>> On Jun 7, 2020, at 11:22 AM, Carsten Bormann wrote: >>>=20 >>> Hi Laurence. >>>=20 >>>>=20 >>>> How about stating it like this? >>>=20 >>> We could, but stating for every encoded CBOR data item that it is = not intended to allow CBOR sequences with 0, 2, or more encoded CBOR = data items in them strikes me as confusing. >>>=20 >>> If I read a book about tomatoes, I would be confused if that states = again and again for some content that that does not apply to apples. >>>=20 >>>> While tag 24 can contain a sequence of length one, it cannot = contain most sequences as defined in 8742.=20 >>>=20 >>> Yes, and we can be abundantly clear about that, see PR #200. >>> Without mentioning CBOR sequences. >>>=20 >>> [=E2=80=A6] >>>> QCBOR is fine with sequences or not as input. >>>=20 >>> That is certainly a valid way to do things, but that should be made = obvious at the API. >>>=20 >>>> The CBOR playground doesn=E2=80=99t allow sequences. >>>=20 >>> Right, because it was written before we got a handle on how useful = sequences are as a separate concept. >>>=20 >>>> Personally, I still think it would be better to relax the = distinction and allow tag 24 to carry sequences rather than define a new = tag. >>>=20 >>> That would add some confusion between CBOR data items and CBOR = sequences, so for me that would be a change for the worse. >>>=20 >>>> It is a broadening, not a narrowing so it doesn=E2=80=99t break = anything. There=E2=80=99s no backwards compatibility issue just like = there was no backwards compatibility issue for 7049 when 8742 was = published.=20 >>>=20 >>> There is a backwards compatibility issue: Without the change, both = sides of the communication can rely to get what they expect =E2=80=94 = one CBOR data item. After the change, new implementations might start = to send two, and that kills backwards compatibility with old = implementations. >>>=20 >>>> If not relaxing the distinction and a new tag is defined for 8742, = maybe 3.4.5.1 should say that 8742 CBOR sequences are invalid as content = for tag 24. >>>=20 >>> It does so (and more so with #200), but not with these exact words. >>>=20 >>>> It is OK for CBORbis to make normative reference to 8742. >>>=20 >>> Actually, no (that would be a downref). But that did not stop us = from putting in informative references. I just don=E2=80=99t think we = need another one here; PR #200 is about as far as we want to go here = before we add confusion. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> _______________________________________________ >>> CBOR mailing list >>> CBOR@ietf.org >>> https://www.ietf.org/mailman/listinfo/cbor >>=20 >> _______________________________________________ >> CBOR mailing list >> CBOR@ietf.org >> https://www.ietf.org/mailman/listinfo/cbor >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Jun 25 14:26:43 2020 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 773993A102C for ; Thu, 25 Jun 2020 14:26:41 -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 BoQy_CHPJJLI for ; Thu, 25 Jun 2020 14:26:40 -0700 (PDT) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B233A0FE8 for ; Thu, 25 Jun 2020 14:26:40 -0700 (PDT) IronPort-SDR: p0EVqwwWFNqPDdV1n2IsS+lgFZVSL0wNVKQ9BL/nCdZFFz7fqpFCzi7/qdrajFjX9T/QK8BSzN l+oo5P1+cI1A== X-IronPort-AV: E=McAfee;i="6000,8403,9663"; a="124732001" X-IronPort-AV: E=Sophos;i="5.75,280,1589266800"; d="scan'208";a="124732001" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2020 14:26:39 -0700 IronPort-SDR: 0jej7F3tnU3I/YCzeCentJRCfq31QHoHVEmJBWBX9HD/+QZQ3rblv2Jn0Mb6GpzlaV7ywyoTvq GCd6M7BZjHNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,280,1589266800"; d="scan'208";a="294013131" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 25 Jun 2020 14:26:39 -0700 Received: from tjmaciei-mobl1.localnet (10.254.75.76) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jun 2020 14:26:39 -0700 From: Thiago Macieira To: Date: Thu, 25 Jun 2020 14:21:04 -0700 Message-ID: <3711670.EONp55a9Cx@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.254.75.76] Archived-At: Subject: Re: [Cbor] Registering a standard tag for QCBOR sequences (was Re: tag 24, CBOR sequence and non-CBOR sequence) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 21:26:42 -0000 On Thursday, 25 June 2020 14:08:50 PDT Carsten Bormann wrote: > > It does seem like this should be a full standard tag since tag 24 is a > > full standard tag, > I don=E2=80=99t know what a full standard tag is. RFC 7049 =C2=A77.2 "Tags registry" says New entries in the range 0 to 23 are assigned by Standards Action. New entries in the range 24 to 255 are assigned by Specification Required. New entries in the range 256 to 18446744073709551615 are assigned by First Come First Served. I guess Laurence got it wrong, tag 24 is not a Standards tag. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products From nobody Thu Jun 25 21:12:42 2020 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 2052B3A110D for ; Thu, 25 Jun 2020 21:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znca53vPlDcP for ; Thu, 25 Jun 2020 21:12:38 -0700 (PDT) Received: from p3plsmtpa11-05.prod.phx3.secureserver.net (p3plsmtpa11-05.prod.phx3.secureserver.net [68.178.252.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A063A3A110B for ; Thu, 25 Jun 2020 21:12:38 -0700 (PDT) Received: from laurences-mbp.lan ([70.58.199.219]) by :SMTPAUTH: with ESMTPA id ofjAjEQLN1kv9ofjBjUFR3; Thu, 25 Jun 2020 21:12:38 -0700 X-CMAE-Analysis: v=2.3 cv=c9bVvi1l c=1 sm=1 tr=0 a=vYbQBYz1awqCo8DrEKtgEg==:117 a=vYbQBYz1awqCo8DrEKtgEg==:17 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=1nqKGKF2XMCcpPoekM0A:9 a=9Fo_igN3tN7ULmWD:21 a=gY4l1nBbIx8ut0YQ:21 a=QEXdDO2ut3YA:10 a=ASDIIGiCKmIA:10 a=-a6rqvgO-m4A:10 a=Kq6-M8QXwFQVLdYD1b0A:9 a=IKnWfIUKmyZbmbhQ:21 a=foLIOa2gjA-hdg_w:21 a=oDeg3x6fzLYz-M4o:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <168D68F8-8F32-475B-BCE6-AED9121C556E@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_55291F23-6B80-413C-8AC8-3E832AB4221B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 21:12:36 -0700 In-Reply-To: <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> Cc: cbor@ietf.org To: Carsten Bormann References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-CMAE-Envelope: MS4wfHdVRkeA14zC1WKwD62qjB34vC3LG3353Rx82H+yiG+SmpdCey8gatI3XHLj2gwy0hnZzduc5wEk6+VLX0353cnATTrllGOZNg9ewXKNr/paAfn1VVlW xm2wtetZIb8P9lgzGralx+38gRNIzoBV9cORGp/GzJviB8Lg/MuvnsoJY+QGJupKZhTnIscD/MEipQ== Archived-At: Subject: Re: [Cbor] Registering a standard tag for QCBOR sequences (was Re: tag 24, CBOR sequence and non-CBOR sequence) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 04:12:40 -0000 --Apple-Mail=_55291F23-6B80-413C-8AC8-3E832AB4221B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Off by one error on my part (23 ia standard). No complaints about tag 63 in the notable tags doc (though the registry = is where I mostly look and expect others will because it has all the = tags). Thanks. LL > On Jun 25, 2020, at 2:08 PM, Carsten Bormann wrote: >=20 > Hi Laurence, >=20 > On 2020-06-25, at 22:22, Laurence Lundblade > wrote: >=20 >> So we do need to register / assign a tag for bstr wrapped CBOR = sequences. >=20 > Yes. >=20 >> I can=E2=80=99t complete the implementation I=E2=80=99m working on = until I know assigned tag number. We kind of have a (small) hole in CBOR = without the definition of this tag. >=20 > Yes. Fortunately, registering a tag is low-threshold. >=20 >> It does seem like this should be a full standard tag since tag 24 is = a full standard tag, >=20 > I don=E2=80=99t know what a full standard tag is. >=20 >> so maybe tag 20? >=20 > 20 is a 1+0 tag, of which only 12 are left. > 24 is 1+1, so the equivalent for CBOR Sequences should have a 1+1 tag, = too. > 63, the number we registered as a Content-Format ID for = application/cbor-seq, happens to be free, so I am proposing that we use = that as a tag number as well (we have achieved this little piece of = mnemonic economy before). >=20 >> Seems the obvious place to do it is in CBORbis, if it=E2=80=99s not = too late. >=20 > CBORbis is not intended to have additions to RFC 7049. > We already solved this problem once (for the invalid tags) using the = notable-tags document. > I published an update to notable-tags that specifies the new tag in=20 >=20 > https://www.ietf.org/id/draft-bormann-cbor-notable-tags-02.html = >=20 > and, in the interest of expedience, went ahead and asked IANA to = register the tag. >=20 > Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_55291F23-6B80-413C-8AC8-3E832AB4221B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Off = by one error on my part (23 ia standard).

No complaints about tag 63 in the = notable tags doc (though the registry is where I mostly look and expect = others will because it has all the tags).

Thanks.
LL

On Jun = 25, 2020, at 2:08 PM, Carsten Bormann <cabo@tzi.org> wrote:

Hi Laurence,

On 2020-06-25, at 22:22, = Laurence Lundblade <lgl@island-resort.com> wrote:

So we do need to register / assign a = tag for bstr wrapped CBOR sequences.

Yes.

I = can=E2=80=99t complete the implementation I=E2=80=99m working on until I = know assigned tag number. We kind of have a (small) hole in CBOR without = the definition of this tag.

Yes.  Fortunately, = registering a tag is low-threshold.

It does seem like this should be a = full standard tag since tag 24 is a full standard tag,

I don=E2=80=99t know what a full standard tag is.

so = maybe tag 20?

20 is a 1+0 tag, of which only 12 are left.
24 is 1+1, so the equivalent for = CBOR Sequences should have a 1+1 tag, too.
63, the number we registered as a Content-Format ID for = application/cbor-seq, happens to be free, so I am proposing that we use = that as a tag number as well (we have achieved this little piece of = mnemonic economy before).

Seems the obvious place to do it is = in CBORbis, if it=E2=80=99s not too late.

CBORbis is not intended to have = additions to RFC 7049.
We already solved this problem once (for the invalid tags) = using the notable-tags document.
I published an update to notable-tags that specifies the new = tag in 

https://www.ietf.org/id/draft-bormann-cbor-notable-tags-02.html=

and, in the = interest of expedience, went ahead and asked IANA to register the = tag.

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

= --Apple-Mail=_55291F23-6B80-413C-8AC8-3E832AB4221B-- From nobody Sat Jun 27 00:36:42 2020 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 9FB9D3A0112; Sat, 27 Jun 2020 00:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOi9UTV0ETF8; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D98E3A02BE; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49v5Cw3B9zzyWX; Sat, 27 Jun 2020 09:36:28 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614936187.9916019-bef90aaa2d26cc00a43c1ed5be064893 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 27 Jun 2020 09:36:28 +0200 Message-Id: To: Ace Wg , core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Constrained Node/Network Cluster @ IETF108: DRAFT AGENDA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 07:36:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF108. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't know what that slot on Friday is supposed to be. All times appear to be in UTC, even though nothing says so; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG Rm 5 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 2 SEC *** teep Trusted Execution Environment = Provisioning WG 1300-1350 Session II Rm 4 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 6 INT intarea Internet Area Working Group WG Rm 2 RTG babel Babel routing protocol WG Rm 5 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 5 ART webtrans WebTransport WG Rm 4 IRTF qirg Quantum Internet Research Group Rm 2 SEC gnap Grant Negotiation and Authorization = Protocol WG TUESDAY, July 28, 2020 1100-1240 Session I Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things BOF Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG 1300-1350 Session II Rm 4 SEC mls Messaging Layer Security WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 4 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 3 SEC *** suit Software Updates for Internet of Things = WG Rm 2 TSV loops Local Optimizations on Path Segments BOF WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 4 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG Rm 2 TSV quic QUIC WG 1300-1350 Session II Rm 6 ART webtrans WebTransport WG Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 4 RTG rift Routing In Fat Trees WG Rm 5 SEC *** cose CBOR Object Signing and Encryption WG Rm 1 TSV tsvarea Transport Area Open Meeting THURSDAY, July 30, 2020 1100-1240 Session I Rm 6 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG raw Reliable and Available Wireless WG Rm 5 SEC secdispatch Security Dispatch WG Rm 2 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 2 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 6 INT add Adaptive DNS Discovery WG Rm 7 INT *** drip Drone Remote ID Protocol WG Rm 4 SEC acme Automated Certificate Management = Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 8 ART *** core Constrained RESTful Environments WG Rm 6 GEN hackathon Hackathon Rm 2 SEC tls Transport Layer Security WG Rm 1 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 ART wpack Web Packaging WG Rm 4 INT 6man IPv6 Maintenance WG Rm 6 SEC emu EAP Method Update WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 7 IRTF coinrg Computing in the Network Research Group Rm 3 SEC privacypass Privacy Pass WG From nobody Sat Jun 27 04:01:59 2020 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 A4C6E3A00E0 for ; Sat, 27 Jun 2020 04:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18mSp7U7ocyS for ; Sat, 27 Jun 2020 04:01:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6923F3A00DF for ; Sat, 27 Jun 2020 04:01:50 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49v9mq3LtnzyXr; Sat, 27 Jun 2020 13:01:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <168D68F8-8F32-475B-BCE6-AED9121C556E@island-resort.com> Date: Sat, 27 Jun 2020 13:01:47 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 614948506.959862-676dbe031ac485536b412b027ae5ff08 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1811F0B6-3105-4904-987A-72D0BC14D719@island-resort.com> <1B46F405-BF3C-44C7-B154-53AD503AA716@tzi.org> <66E842EB-E590-42C0-9F56-C79B3A077E92@island-resort.com> <55292D97-F21E-46CF-9F00-C313AAAD400E@tzi.org> <42B71DEB-223D-4E93-B786-BD2CDF6ED581@tzi.org> <168D68F8-8F32-475B-BCE6-AED9121C556E@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Registering a standard tag for QCBOR sequences (was Re: tag 24, CBOR sequence and non-CBOR sequence) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 11:01:57 -0000 On 2020-06-26, at 06:12, Laurence Lundblade = wrote: >=20 > No complaints about tag 63 in the notable tags doc (though the = registry is where I mostly look and expect others will because it has = all the tags). Good. The registry now has: 63 byte string Encoded CBOR Sequence [RFC8742] = [draft-bormann-cbor-notable-tags-02, Section 2.1] So all should be set for your usage of this in QCBOR. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 15:06:54 2020 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 0DB1E3A090D for ; Tue, 30 Jun 2020 15:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvDmw84iZRKE for ; Tue, 30 Jun 2020 15:06:46 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7463A08D2 for ; Tue, 30 Jun 2020 15:06:46 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xJNh4b3MzyYc; Wed, 1 Jul 2020 00:06:44 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615247603.350849-2b933708f59cd82e127c3bcc890e5fad Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Jul 2020 00:06:43 +0200 Message-Id: <4F2A6C32-A89C-472F-AC22-455FA7DF6BC4@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Cbor] Update of OID draft X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 22:06:53 -0000 I put a proposed update of the OID draft up at the branch https://github.com/cabo/cbor-oid/tree/cleanup Please see = https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.= html for the HTML, and, if you want to see the gory details, = https://tools.ietf.org/rfcdiff?url1=3Ddraft-bormann-cbor-tags-oid-06.txt&u= rl2=3Dhttps://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tag= s-oid.txt for the diff from -06. This version removes anything but the actual Object-Identifier tag = definitions (and keeps a little bit of explanatory text around them). Comments welcome (maybe we can discuss this approach, if not details, in = the CBOR Interim today?). If we like that, I=E2=80=99m going to ask for = WG adoption next. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 17:37:16 2020 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 325333A0833; Tue, 30 Jun 2020 17:37:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.6.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cbor@ietf.org Message-ID: <159356383413.16630.13588049762388034539@ietfa.amsl.com> Date: Tue, 30 Jun 2020 17:37:14 -0700 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-date-tag-02.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:37:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise Binary Object Representation (CBOR) Tags for Date Authors : Michael B. Jones Anthony Nadalin Jörg Richter Filename : draft-ietf-cbor-date-tag-02.txt Pages : 5 Date : 2020-06-30 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC 3339 date/time string) and tag 1 (Posix "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applications needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-date-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-date-tag-02 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-date-tag-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-date-tag-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 30 17:41:31 2020 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 669F83A0837; Tue, 30 Jun 2020 17:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_DFuIXGCIvb; Tue, 30 Jun 2020 17:41:27 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650100.outbound.protection.outlook.com [40.107.65.100]) (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 75DF93A0838; Tue, 30 Jun 2020 17:41:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M0aLCK8OWdnMp/rJCSSJbSFhPFxkrkuyq3Rzj6jgTRYWndU+xz/YzvIirom9cV/1dkbwAqAkTDHK99u/BZTt/MhVnw0ZwQUTpYjjXhMCm2xFTdVJxTsGwaUL8Y5fYRHLXSkgdZXpZ+BaI8OmLxfvKUf7WuzRJmzXjJJsNhp8pbpKRCqxNKIqOzhFkOIJAsWdclnvoEzxO4RFLBNE6QiaklJoh4U1/tiQq/2ud4c26H2FYdSg8dH+OzZ+du++LIRO+Zc+7+vjkpyF4Wk6tA51d4FUUj2hyvBoE2ZoHEpHUJalfi5YtG5MSUPfegJV7Ac7yRyAPnKvA0JqGvS5A/kBFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jJXH4cnIvyiCqOYBEU+CDT+ezZUrHz7CeHXwc5NhgMY=; b=ftVletZmfVErI4ZAoi7BYWNbZPG223mpR7w51dNso8C/JzfxK3TIXbWG9KMEnG1lKkox/wDniEmb0rV+pu+4ZILBD1GYdXX/5cs+R2oMYdNlkJn7OI9QtrqK95/UQ7YNMApvI8vQ2nv8P4o8PYIs7zgfUSuz83Eck239+p4vArtW2sLvfozRaCzfHkiTZ35/NX0q6k4MQ8Ql1l5NnovAaisLJUgDV+Et+XwbEeR9V2Rkvg03iyfoRcSbuiKbVwSnwrfaB6kBbQN4Xo/CO5XlB/rnhjHnq0UXlYDiXc6HElMdduo6zdwroVS1xbJZMtybwzA6ToVLsbrOWX+8Kyis6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jJXH4cnIvyiCqOYBEU+CDT+ezZUrHz7CeHXwc5NhgMY=; b=XlyrN5meldYmbAZRVtuWmeyPlWg0bvp/q6iG9HwBF8hLiyA6Jm5gGWVfXpd9sbEofCBacTDJrNnyaFTix/gRPxPOssrZAkDSTffBSBa4ebNcpD96NTSOg3Y6TQbyVG4ncDSwg4ZTnhWlwK4AO+sUsZb/prKfvnKqLVXSRZw8wvc= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0841.namprd00.prod.outlook.com (2603:10b6:610:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3184.0; Wed, 1 Jul 2020 00:41:25 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d%8]) with mapi id 15.20.3190.000; Wed, 1 Jul 2020 00:41:25 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" CC: "cbor@ietf.org" Thread-Topic: Review draft-ietf-cbor-date-tag-01 Thread-Index: AdZA6oYHrsep9MdnQn2dj3B2XcVwEAOVXHVQ Date: Wed, 1 Jul 2020 00:41:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7329b5d3-6b53-42a1-8573-362e5da544a9; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-12T18:45:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bbced0ff-05c5-4d19-6a70-08d81d577c44 x-ms-traffictypediagnostic: CH2PR00MB0841: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MUhWNpvMZ+mworZPzB0pbSQnf9sdo1uPM2PdXHkc1mO7e64L3muJ8a8+wy1pGq6HnVppqWEZXd4naWxo6ep+crSpHrP0PHvSLO/SmOuYNQgYMEIih1jP6DdMgX/70FAYgaTef9sScJfbwIWgZnFHua1HYm4TawYO0PoUu26vEMapjBkNBdFZcV1oQa1JUZdRBVtEB6vb5jvE9qdWFgutUredujtLbtGjJdLgmywtGq78thi1qw3+EHCn82Hb2jikJ9r5tq6GBFSt/IhJAmucexnm1UKn8ZmTT0+UfMhUVcrRIWcDKEr2BG9qggifYpMhNQFWkl0Ljcs4jCy+8X25gr74yJZ5w4uHjxjSstxafsm1GgShxdXVk8aiofbwxxwFGwq9fjp5+IU50faZCzcJtA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(76116006)(478600001)(8676002)(82960400001)(86362001)(186003)(82950400001)(10290500003)(2906002)(5660300002)(8936002)(52536014)(6506007)(66556008)(64756008)(7696005)(66446008)(55016002)(66946007)(33656002)(66476007)(26005)(9686003)(83380400001)(316002)(71200400001)(966005)(53546011)(8990500004)(110136005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: UJBwMKVxnQI9Ai4FWCgPgFJGNlu13SPEzLwVyLwamws3L5kLeuWamd4tVQg4mIekuJfdNi45aVSq6Yrxz7u1+twAzhc48+BChM3AVE3NgFFjSqc3Cl6CZm4zGijauVcJFfyZBB+dBsC8uCRJvBeyBxFcw5LyBCB8bo5mKNI7AMkPk1iOrGoMCFwRksTyH+HzCcFRBDX8haQVgJ0i8gmfGSD2Dlp9wcbMuluXBtlbZokHDBkFc9Yr7FWW/ZaHbRiWd1i6XTCuEpMbVrQ65EnDvJ4mhOVQD8VspqSI4NjK41NmvrdH/IRzh57zp1yg7yJot3f9JemPrsvaVSKMahHMwgnL0JRn/eNzauJswBCtmyOhwUuar/ikwMVbXjKWAeNxwv+CoWwauY6spwD5rQJeBxt6vHJA/GeivZ8nJQSqZN9EQ0x2Jn1M76z/uCFT2eN771pSc/PJb+/6UVf+xxtYQUsAOt1SnaAs74dhdvAjE4I= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbced0ff-05c5-4d19-6a70-08d81d577c44 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 00:41:25.5889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mxP8K7WMBhl81CUCqm5QU7krEYGPXb2o2cHvT39P7RM6g95QCuo3IyDLoJMrB5SQnRCzZJ7d/TVu9Rzu1FnZMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0841 Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:41:29 -0000 Hi Jim, I've applied these changes in https://tools.ietf.org/html/draft-ietf-cbor-d= ate-tag-02. Thanks again, -- Mike -----Original Message----- From: Mike Jones=20 Sent: Friday, June 12, 2020 11:52 AM To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Subject: RE: Review draft-ietf-cbor-date-tag-01 Thanks for your review, Jim. My replies are inline below... Is it time to start WGLC so others also get their reviews in? I'll note th= at the IANA registrations have already occurred at https://www.iana.org/ass= ignments/cbor-tags/cbor-tags.xhtml. -----Original Message----- From: Jim Schaad =20 Sent: Thursday, June 11, 2020 11:48 AM To: draft-ietf-cbor-date-tag@ietf.org Cc: cbor@ietf.org Subject: Review draft-ietf-cbor-date-tag-01 * Is there any chance that you can upgrade to using the v3 of xml2rfc schem= a? If not then there is not an issue as the RFC Editor will do it. I haven't really learned all the ins and outs of the new syntax yet, so I'd= have more confidence with the RFC Editor doing it correctly than me. * Introduction: I prefer the abstract form of /date but not a time/date wi= thout a time/ I agree and will make this change in the next published draft. * While this is something that is clear to me, I got a recent comment when = I suggested that this be used elsewhere of, "But how does this work with ti= me zones?". Based on that I think that there needs to be some text about w= hy time zones are not of interest here. Agreed and will do. * Section 3- I think that the second paragraph would be wise to distinguish= between a point in time and a date when looking at access control decision= s. I understand your point in general. Is there particular text that you'd su= ggest that I incorporate? Jim Thanks again, -- Mike From nobody Tue Jun 30 17:41:56 2020 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 65D013A0838; Tue, 30 Jun 2020 17:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dIxke5O50MZ; Tue, 30 Jun 2020 17:41:52 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650108.outbound.protection.outlook.com [40.107.65.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C9F3A0837; Tue, 30 Jun 2020 17:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dJPijQ/nu0NPRuC02O7FuyjZ2MP6oQia0dN0F+jDRKEcXAOxaVXX3+0KlpXUhFg82x+cZYZ6yoNxQCEZWmPrfI/d0knPulNqj02lOlg+sbq/zq4UTqaF3BT0zaqRdcKx5dCVQmUEI64SVwbX9jAVj0jGF58DmJH5bDEuboi+0Z2+2VXgwcgdV63MMhYha78uCOdkdRG6XuFjJnIh8wDldgm1XNrcb3tKwoMwpkXIReQTsCwk9IzJLXziHSTQUBVKkIxbfufaxd2rQCxYPS5fHck4TocPu1D8o8DAh47ptroP/pQJ0pjlkUOVGVwZ7r+eLyB9mvGR8Y1IYa8ki2P4XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NQ0JJvanthr3Gl3+anQUzxp/mzWDJenU5sqNDVVaukk=; b=lhmUmMfFZH45XGAAc+RMXNVWzAj1XtHlpnpEGLNLv2uNAQX9RalcjUW6Lh784sbEbhmbshMI8QYcPzBNlXlU+IsR7t+/KpQn3erloTFiNOeLxNx3iJFX7Y0tigPSVfTfZPd4LSmAazi0V3zIlND8t09aA5+7GRJjlStGy6Hh46mpAQjKW75qqvA87ksZiqEkw/YD2YyVFKHL1pGWU7rvrVmItkiiutn9Hyd3kPj6ezNl40pvDlKo/mSbtCtuB0IVX9VOTTXY9j6y7XbmtSy0ydajqZWSgFDQKQmMy4z5z9Otn7qV38KZ1aNqVoun49/Jd7MZVM829owCFuVnUxg6Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NQ0JJvanthr3Gl3+anQUzxp/mzWDJenU5sqNDVVaukk=; b=OapXT085Ygli+OCyfvl4Sm5R3uoSgO9rrbGn12KPZZZg1Q2qrcuuZ2HUjNbuZxCDaFNnOhuCi9njfYKQKKDY060JCr5UE7N5FGaVvldvCXAtYUzCZV7i1JlYnGY1v7fkjOMHvsYeNPt9UJ/+8p2+Qfv2xSbfHaLcEguPCRpajjg= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0841.namprd00.prod.outlook.com (2603:10b6:610:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3184.0; Wed, 1 Jul 2020 00:41:51 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d%8]) with mapi id 15.20.3190.000; Wed, 1 Jul 2020 00:41:51 +0000 From: Mike Jones To: Carsten Bormann , Mike Jones CC: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" , "cbor@ietf.org" Thread-Topic: [Cbor] Review draft-ietf-cbor-date-tag-01 Thread-Index: AdZPQGTqeiOLcx+jQhyRLFg6aZtSLw== Date: Wed, 1 Jul 2020 00:41:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ae9f3fd5-0e1c-4ff5-84f5-fb436c1a6181; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-01T00:39:15Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b0f1e991-1b3e-48a4-3bbd-08d81d578b72 x-ms-traffictypediagnostic: CH2PR00MB0841: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wAGoLDnhx9jbafnuHdpAGfTxWNV+YNJhDPdBzQ9Z/9LsBHF3cRhy/SbYZ/pqgjJqujMqgeY1NnPzsdCknigsAliiVUiN4y8c71cul3e3EKZ64Qjpml/U9oGFR0Hrt5Qwqo+BFGeAFQqonnNm38fMaqwuc5Y0mwuhYxxzPqxktSDT/nSfFewzunW5BR/rh16JI2rHYDkN+l1NVJ6wPuFBRtmLz+UsQHT1Uc/3yZgjFx0wagMFiRr8RHrqIb1en8zlALnSYDhxeUvx8rqsNxT8fEOVVk6XgD2GSEbTX+yOHkXs3PSryw2F2PvNs9N2AGj0UznHyfpc2ejvE9d1/jWHCI8/lT1ORHDfg5rLba3ev0y8bDJHcOeKzYfHXuPWhZev1/Q2aTKYaD4e+FD2KjAyvQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(76116006)(478600001)(8676002)(82960400001)(86362001)(186003)(82950400001)(54906003)(10290500003)(2906002)(5660300002)(8936002)(52536014)(4744005)(6506007)(66556008)(64756008)(7696005)(66446008)(55016002)(66946007)(33656002)(66476007)(26005)(9686003)(83380400001)(316002)(71200400001)(966005)(53546011)(8990500004)(110136005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7XM7XOfqkC3bJbOIkBhaUZOPs5tj4msDhvmB+k24QwDEfROX7968uuoxnnj8s6Q9mRyb+ubRYNGF+qWW8wT1MQwv3AHKj+6IiMrHZS67/YmF4XJqFNEHDCO/v50b6uCPoOyJ9yEHBp3p+673cjCLNKRJFChW7F9impuzhg/hVLcIWNRYlVUSDeZ89tasfTMlV4k79ZTV1/dZb6Kpy0OL0vB3UmSkGDs6/zqI7Xc8+Qhj0CxyLJ+BfCnE10qAvqXavi5ZeBh0deoIom1pDFs6MatZrK90bagOG+XLkhqp19g6YMg238fIQLq5B5u/AMFm0MJFtdcAWcO56P7uRVIxZ+CEwOaOM38zdM8ht/fuKE17q/8/vcuxIGEeM4ngGscQjXdVvlrV2JIZJoCC9RAsxqqlcgXhnwFES5+yoIzi7ZDLOIu99wx++ylX6/XZVMJCBFH+eocpmSYuNrOoyGje9D/RvgOSoyAoMefgVkn6/f8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0f1e991-1b3e-48a4-3bbd-08d81d578b72 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 00:41:51.0450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1V80TpQYOBNuR3l4Klpcd89YpD9B6+3ZsEd16AhTy1IlykhUsLdy5eqQEous4l96dz2zcmxe+L5Wt+4Z8Lia0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0841 Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:41:55 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhlIHRpbWV6b25lLWxlc3NuZXNzIG9mIHRoZSB0d28gdGFncyBpcyBu b3cgZXhwcmVzc2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNi b3ItZGF0ZS10YWctMDIuDQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5v cmc+IA0KU2VudDogVHVlc2RheSwgSnVuZSAxNiwgMjAyMCAxMDo0MyBQTQ0KVG86IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IEpp bSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBkcmFmdC1pZXRmLWNib3ItZGF0ZS10 YWdAaWV0Zi5vcmc7IGNib3JAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ2Jvcl0gUmV2aWV3IGRy YWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMQ0KDQpJIHNlbnQgc29tZSBuaXRzIGZyb20gYSBxdWlj ayByZXZpZXcgb2YgLTAxIHRvIHRoZSBhdXRob3JzLg0KDQpUaGUgb25lIGl0ZW0gdGhhdCB3aWxs IG5lZWQgYSBsaXR0bGUgbW9yZSB3b3JrOg0KSSBhbHNvIGFncmVlIHdpdGggSmltIHRoYXQgd2Ug bmVlZCB0byBzYXkgc29tZXRoaW5nIGFib3V0IHRoZSB0aW1lem9uZS1sZXNzbmVzcyBvZiB0aGUg dHdvIHRhZ3MuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K From nobody Tue Jun 30 17:42:08 2020 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 A41FA3A0838 for ; Tue, 30 Jun 2020 17:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTYEu0HdcXyt for ; Tue, 30 Jun 2020 17:42:06 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (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 300D43A0837 for ; Tue, 30 Jun 2020 17:42:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ocpFU3XytTIII1/rVeK5sprhbUhcZMx/wT4+wYWK1DEAcMUsnM4SlmI38ySO1RjyBfFSJZ3lXTfShjnHDU05h1CAe/U0HuqWckQf3J4VPwS+n00r8C6Xq042rygs3lX0FHNElFao8sNrVCUIC4FD0ijNEhRMWc+vNFxCjgC8P0GsZkZNfA+CU/Yi7YG/kLstmk0XZtead+TuMdJ2wheUsYV9yKK2AeePTjzVRuB1NpGQaNvIpWZX8HgDiu63x3Eea+MfQtU/jLTGUlQeVHRatu29xbXJCzKQoWxegKEIov7l55aulwqlfAyf1yVldLE6BMgDXcuR8WkT3bniHmhTPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lJWfz/pgC/aXELy8nN9WCLaEi2sZMeF2WOYG06ak/Hg=; b=gikA3nQrvre+vzj/K/kEz0bKYSUdIciQORSbvAOj7+ILEi/1HrzQqMPrjAvQHBcNi/ljnVeLG/QyYzdgMdjWfp8OqSqyOTtCBHjQVgJT6oPaSrIhbg8+clNfIRGxTELoG5yyOWQ36EMQuH0lr/srwKbRYTOIY3VkqaKWNzuOaNiceE4Eeo/ghP98YfUeNeURqeLum/G+aVYQ0QgOI+f1v5ONqJiDs5Ts6il8yFPuhi4HFkJ6Sw/nKIA8YA59RCOEYhM2CUWYQdXyL+6vLiUf9OO7SI/NfG6bXqUUc2NUC2ZiNhj+LBrQFHy/+I7Ba526Z+T/xPtv53KFrVPjpPFtFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lJWfz/pgC/aXELy8nN9WCLaEi2sZMeF2WOYG06ak/Hg=; b=Wg3E1fQdZ8rtxZmaFmNnvr1toHl4g34Sx38sBf5YVEu+qkBacswcveDV+yNS+NL2649nrgns4XfY1vQoT4xJU7Jdh8+vp4lFXmJwdEmYnvEe4/ihFGMZ86lS0Uaw+xth1lh5ZqyBVcYPLqTX4/ljfUyv4+wF1lgH1FWuy6UhISM= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0841.namprd00.prod.outlook.com (2603:10b6:610:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3184.0; Wed, 1 Jul 2020 00:42:04 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d%8]) with mapi id 15.20.3190.000; Wed, 1 Jul 2020 00:42:04 +0000 From: Mike Jones To: "Dale R. Worley" , Jim Schaad CC: "cbor@ietf.org" Thread-Topic: [Cbor] WGLC on draft-ietf-cbor-date-tag-01 Thread-Index: AdZPQG6blgXbomgSSp6Zp+okFYd3ew== Date: Wed, 1 Jul 2020 00:42:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ed94283b-1ad7-4a38-84d4-b53e7cfad12e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-01T00:40:05Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 92d832af-9bc7-4910-fa93-08d81d57936a x-ms-traffictypediagnostic: CH2PR00MB0841: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tXpZVoavjll3CaaCxB1Q1DFZigLBpOOLOrxWb+daOzaEjsqF89GubXO1H86HFJlNRyi49SnsLEUWI2sOMl9XoQaaTDVoZYP6x46qfh5TaQPrfR4kHvGSaq8X7HP8buH2OmQMX+Kv1vo5zSaJcvMG3SXU6rIh5HI8ov28U3JHYgDjqWW7QeeaWCmCjFnPn8C+psfR/Kz9debkeRFtLIkTGj3gKHQHHdX4XEXQSDg2DaztZlShci3BaI8JG8pgiUaKgv8YGNl/Z56RFAWppsog7+cyz5WNwgw+smUV9rysfGcmpn1TQeESr40XEpc7Rz38XuBijcY5yl2amcO67n+n27bFAMvSh6W+NV+FjWcq9Gi+kFs4DW4RsHJx5gQTyyRw3eTftDMClRWY94EDfLQolg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(76116006)(478600001)(8676002)(82960400001)(86362001)(186003)(82950400001)(10290500003)(2906002)(5660300002)(8936002)(52536014)(6506007)(66556008)(64756008)(7696005)(66446008)(55016002)(66946007)(33656002)(66476007)(26005)(9686003)(83380400001)(316002)(71200400001)(966005)(53546011)(8990500004)(110136005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Cfa8osOL2Biy4pwNo9ghlsaSL/TQ/Yx4ORitHFs1JFdXal9U1I1IrB+bh2RX/uf01zlXNZE2PqHWKlrI91kZN2/tKr8TI6/Geb5rL0ttbiWLoJfJUq/Tux6MNEsjL4iYkpvbOjyNXlRKR09RD3U9eReJFvgkbx8qpS3r78gK19g9nU2O/EPhsEz489Vq/7MENq5wEHyW1siKIPTfXYLyp2Q7Mhgw3C7o+/HDzyoS+kmnMWpq9TBbtKn9+XhUFukkS8MmkbeKBQ38LPFB/92EISdccJ60ci36Kywo5j7Wmn8unIhDyNCxQM8+lhGzM/dgZBW+yACjMVejuxa2umm/hCLtlqc8fcyLEU5CkU57urbjlUfuE+0VK07ouzckSR8p5X6d4XoRjgPB6xGqKu7xNj8ESzMmNZXPK+HI36PvQNcGsDoZlbFK7NV3FQoZ2ACNr0bK/vBXSdZF7VWYMjznc8aax/1u1eZZ0ArYBF65NKw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 92d832af-9bc7-4910-fa93-08d81d57936a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 00:42:04.4123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wpETaKEBPpTyMKraHsRndU8SS/XD+ICGhuUw9CauE384lLKSGpb+Xa4d/ff51p9nJIHD5wK19pfuE+OFC76ttg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0841 Archived-At: Subject: Re: [Cbor] WGLC on draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:42:08 -0000 Hi Dale, The leap second-lessness of the two tags is now expressed in https://tools.= ietf.org/html/draft-ietf-cbor-date-tag-02. Thanks again, -- Mike -----Original Message----- From: CBOR On Behalf Of Dale R. Worley Sent: Wednesday, June 24, 2020 6:28 PM To: Jim Schaad Cc: cbor@ietf.org Subject: Re: [Cbor] WGLC on draft-ietf-cbor-date-tag-01 Jim Schaad writes: > Hey people, I would really like to see a couple of more comments from=20 > people even if it is just - yeah looks good to me. Not that I'm an expert in time, but reviewing -01, I couldn't find any tric= ky ambiguity about leap seconds, which is where time formats usually fall d= own -- RFC 3339 specifies how leap seconds are to be designated, and when c= ounting days, leap seconds are automatically included. Since tag numbers are not a limited resource, there's no need to worry whet= her this is the best possible way to encode these data. So it looks good to me. Dale _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor From nobody Tue Jun 30 17:43:16 2020 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 0696F3A0839 for ; Tue, 30 Jun 2020 17:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn2_zXB1BhSN for ; Tue, 30 Jun 2020 17:43:12 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650101.outbound.protection.outlook.com [40.107.65.101]) (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 2A0E23A0837 for ; Tue, 30 Jun 2020 17:43:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uic5OnAKOTecaHsql+gBSZZHCtdFD80hWOkhHtaY5TmDuI9EIBOjBM9QPx1KS/jP5HLlIiB03aTMXAqGRBMS1hzKm8WQPobILaNv3fSr99Wm8XxAXIaBPpQE/aZ7WIYofL2TQy72Ugiaps3sgD4Kg41ZhXql6ptrcE15Rrk+4qqvtqZMq1Dmux/ZFtAYhOcNK/WyWijlONBrIKWDyxaup79gSzZpCPyWizcjgHJHpKHnv+sNMXuDA/rZdjinZggJwNGy8fuze017uJ0uJEtpZFpLiF9h2C+izAo5F7nQCF2ucst0D3x+4TKGtVemjxBuEZhR3vY59962BUGSFW3s4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rks1MOZ7ClNzIiMTn/ARLKDI6Rwyi4sZLhyykHpWQEU=; b=Y0Co4qVHKZsWvUUv/eb+z596nZ8nel4Vtc4ArD+Qb9e3i/T7YNy1J3vNBYrgKxERKRmppFTUGjoQcEISfPLgAL2e3qOKK2+cZcopVe0KjMoLmMgYrSPPEvf3VpulLU2bOdL/363ZB5ZVkzxl4MZm6OMWmTER1NUh1Dgom90LCXSnsMvXEVhVfYronUUDbTjeZ84TTEQgzPHznzt6BR34wECkuz53bEDzkczUrKHyP4Af/1wzyYzv5oTKgJVS+/doTa7aHgbprEBS+tB9N5NCbx8U7aq7w9tPEqo3QW6VtYmAyJcu3QT7ibA2dm/U5NxbXVHFYfeJJ4i9LCWIId6Dmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rks1MOZ7ClNzIiMTn/ARLKDI6Rwyi4sZLhyykHpWQEU=; b=arFh0Fu9cS+ziN/6wgePHXwBw9tvWm6LIqd2jJSbJw63BlXDM2e6W2Pkss+1J56pUNiBpi7AGgkY3NV72ePHYa1kdeo2MdwUTGnYyFuHVj143I36Wo4Lni/Dy2sCHQcM36X7n4aNTNBe5NQGqxUiiFDxQqB10C05qQblR4wkglk= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0841.namprd00.prod.outlook.com (2603:10b6:610:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3184.0; Wed, 1 Jul 2020 00:43:10 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d%8]) with mapi id 15.20.3190.000; Wed, 1 Jul 2020 00:43:10 +0000 From: Mike Jones To: "cbor@ietf.org" Thread-Topic: [Cbor] I-D Action: draft-ietf-cbor-date-tag-02.txt Thread-Index: AdZPQJa8GI9WsLskQzy0Qji3H9ZhcA== Date: Wed, 1 Jul 2020 00:43:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=831c781d-b1db-4829-a88c-6a6eea107445; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-01T00:42:23Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2e58066f-69a1-49fd-12e6-08d81d57baf9 x-ms-traffictypediagnostic: CH2PR00MB0841: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: POT9g7pDKg2Fp5EbEeY/hgA7EA4Nv8Z7hvjsDqwh1j+EREmddZaGL2Nj15DwBjZbh+dyKjVvkMakwj1P+JzNDXsD6LwFJW2kwV6uDfHue6gxAgeRrfCuiSX6xKMvYk+u0Pf/zCDVNmzZwZRRkG691p0vjq8i7EI2I3cjMzb/0OhimGqaTjMsJ67P9Vvtnfnc61/M4M6em1w5+juadb5gMwSq0wK6f7dQgajmE2NEBVo2SZba48m2yJgfxrIHLGyylKLcsbt1hh6aU0syBSJ8LtpGE5xLMkE+B8UpzHywV6Ru9ekxmf3UnqKQjZTO8IPITECnLo3BEpvU/mJquV5/s7sbEXTdqrdROqbStMltO7t5Pbn6D5fS/V/uq7pktVTsKCTo8tbfyPmYTgPJ6iB/GQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(76116006)(478600001)(8676002)(82960400001)(86362001)(186003)(82950400001)(66574015)(10290500003)(2906002)(5660300002)(8936002)(52536014)(6506007)(6916009)(66556008)(64756008)(7696005)(66446008)(55016002)(66946007)(33656002)(66476007)(26005)(9686003)(83380400001)(316002)(71200400001)(966005)(53546011)(8990500004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RIkq0+EeTNaJv+J3gUAeUpHx67yHcXwHjuBMlGElxE0jzMq0O6i24iMZyBxoPxD3hImPxHQA1vBbIMh/6sI3dU4uQ2Ia/lsr6TYU/34ofgZdRq9QNlcrVqOD2clKKV05I8YbmUYEkj3NoACeiSwozZ81GAGAGOjp+Q5zJB2bSCJ1AR6HRbWWtlZY0JuBTCipgyQPOVai2SjmppwXF1zqoiT8Nivmse0NDQCv6g90d2013+7xZa9XGKSIQF1hQqmU/II4uJxyDj3MMSvhP7HXa7kg9gF3ZSW95N7ERQoepcItrx3996A/JpIuRbr1wvhaSCBgPqT6WP4C/NI8etkDJQkNqHUCieZ2hTQt8yLOkz2a6m0ye7M+9V5wz4yXaaWC/axrqDkz9CvZQO6KhGAY01130w+OUNAoYeigBEsAKxjtDqz1yVufTt51N5/IlnXP4XH9oh1eVQUZYyzieXrqBzJkrFfmBKNFHzmaTd6wp0g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e58066f-69a1-49fd-12e6-08d81d57baf9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 00:43:10.7836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EWdyQbt+jnXknX7eEfbOL01oO3D6ZqaorwoRDb79/DFUaKU+TOG+x/b2csi5N/2t9LBrPD+iptwZEWgl90pCzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0841 Archived-At: Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-date-tag-02.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:43:14 -0000 VGhpcyBkcmFmdCBhZGRyZXNzZXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRz IHJlY2VpdmVkLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogQ0JPUiA8Y2Jvci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDIwIDU6MzcgUE0NClRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBjYm9yQGlldGYub3JnDQpTdWJqZWN0OiBbQ2Jv cl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jYm9yLWRhdGUtdGFnLTAyLnR4dA0KDQoNCkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbmNp c2UgQmluYXJ5IE9iamVjdCBSZXByZXNlbnRhdGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9u cyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBDb25jaXNlIEJp bmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1IpIFRhZ3MgZm9yIERhdGUNCiAgICAgICAg QXV0aG9ycyAgICAgICAgIDogTWljaGFlbCBCLiBKb25lcw0KICAgICAgICAgICAgICAgICAgICAg ICAgICBBbnRob255IE5hZGFsaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgSsO2cmcgUmlj aHRlcg0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMi50eHQN CglQYWdlcyAgICAgICAgICAgOiA1DQoJRGF0ZSAgICAgICAgICAgIDogMjAyMC0wNi0zMA0KDQpB YnN0cmFjdDoNCiAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENC T1IsIFJGQyA3MDQ5KSBpcyBhIGRhdGENCiAgIGZvcm1hdCB3aG9zZSBkZXNpZ24gZ29hbHMgaW5j bHVkZSB0aGUgcG9zc2liaWxpdHkgb2YgZXh0cmVtZWx5IHNtYWxsDQogICBjb2RlIHNpemUsIGZh aXJseSBzbWFsbCBtZXNzYWdlIHNpemUsIGFuZCBleHRlbnNpYmlsaXR5IHdpdGhvdXQgdGhlDQog ICBuZWVkIGZvciB2ZXJzaW9uIG5lZ290aWF0aW9uLg0KDQogICBJbiBDQk9SLCBvbmUgcG9pbnQg b2YgZXh0ZW5zaWJpbGl0eSBpcyB0aGUgZGVmaW5pdGlvbiBvZiBDQk9SIHRhZ3MuDQogICBSRkMg NzA0OSBkZWZpbmVzIHR3byB0YWdzIGZvciB0aW1lOiBDQk9SIHRhZyAwIChSRkMgMzMzOSBkYXRl L3RpbWUNCiAgIHN0cmluZykgYW5kIHRhZyAxIChQb3NpeCAic2Vjb25kcyBzaW5jZSB0aGUgZXBv Y2giKS4gIFNpbmNlIHRoZW4sDQogICBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBoYXZlIGJlY29t ZSBrbm93bi4gIFRoaXMgc3BlY2lmaWNhdGlvbg0KICAgZGVmaW5lcyBhIENCT1IgdGFnIGZvciBh biBSRkMgMzMzOSBkYXRlIHRleHQgc3RyaW5nLCBmb3IgYXBwbGljYXRpb25zDQogICBuZWVkaW5n IGEgdGV4dHVhbCBkYXRlIHJlcHJlc2VudGF0aW9uIHdpdGhvdXQgYSB0aW1lLiAgSXQgYWxzbw0K ICAgZGVmaW5lcyBhIENCT1IgdGFnIGZvciBkYXlzIHNpbmNlIHRoZSBQb3NpeCBlcG9jaCwgZm9y IGFwcGxpY2F0aW9ucw0KICAgbmVlZGluZyBhIG51bWVyaWMgZGF0ZSByZXByZXNlbnRhdGlvbiB3 aXRob3V0IGEgdGltZS4gIEl0IGlzIGludGVuZGVkDQogICBhcyB0aGUgcmVmZXJlbmNlIGRvY3Vt ZW50IGZvciB0aGUgSUFOQSByZWdpc3RyYXRpb24gb2YgdGhlIENCT1IgdGFncw0KICAgZGVmaW5l ZC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2Jvci1kYXRl LXRhZy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2Jvci1kYXRlLXRhZy0wMg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNib3ItZGF0 ZS10YWctMDINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2Jvci1k YXRlLXRhZy0wMg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0JPUiBtYWlsaW5nIGxpc3QNCkNCT1JAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Jvcg0K From nobody Tue Jun 30 17:52:29 2020 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 3F9843A0842 for ; Tue, 30 Jun 2020 17:52:28 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRKsIHS4IHqo for ; Tue, 30 Jun 2020 17:52:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3153A083F for ; Tue, 30 Jun 2020 17:52:26 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 17:52:21 -0700 From: Jim Schaad To: Date: Tue, 30 Jun 2020 17:52:19 -0700 Message-ID: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZPP7lFcxcs7rTWQ96MobGVRLmIuA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Cbor] CDDL Module Design X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:52:28 -0000 Here is a topic that we can potentially discuss tomorrow if there is extra time on the agenda. When looking at a CDDL module design, there are a set of questions that I think need to be addressed: 1. What is the naming scheme to be used? Both XML Schema and ASN.1 use unique identifiers for a module. The problem with this approach is that a revised module has a new identifier even if all of the changes were preserving of the old module. This can also present problems if two different versions of the same module are used as it can be difficult to know which version of a module is being provided. I think therefore it would be nice to have a naming system that recognizes version numbers, but can be used with a "latest version" mode. One possible way to do this would be to use a query parameter to get a specific version of a module while without the query parameter the compiler grabs the most recent version it has. 2. Do want the naming scheme to be used to access a module name from the web, and to create a server to host all of the IETF based CDDL modules? 3. For any number of reasons we need to be able to state that some symbols are going to be imported from a different module. There are some issues around doing a couple of other things: * If all symbols are imported then you either need to have a module based naming system or you need to ensure that there are no collisions. * If only specific symbols are imported, then they could either be a) made to be unique by renaming or b) made to be unique in the current module simply by how the module is written 4. ASN.1 has a method to say that only specific symbols can be exported from a module. I have never used this capability and I am not clear that it would be useful to have here. Should we support it anyway? 5. How should the system be setup to be able to recognize this capability. The suggestion in the freezer document currently is to use a pragma system. Introducing a pragma system can easily be seen as a step to allow for compilers of CDDL to be written. The A2C compiler that I wrote used --# and #-- as the start and stop delimiters for pragmas as "--" is the start/stop comment character. (ASN.1 is not line based so there is no comment till a return.) A similar approach can easily be used here. 6. If we use a pragma naming system, do we want to setup in advance for it to have namespaces so that a single module could be used with different compilers. I ended up using a different string than the OSS compiler did ("--<" ">--") to be able to do this but having a namespace could also support this. 7. What set of pragmas are we looking at to start with. XML Schema has some attributes that can be used for controlling the compiler. One of this is a location hint attribute which can be used for giving alternate locations to use for finding a module (such as a location on my machine). There might be some other pragmas that might be useful to specify as well. It might be easier to specify co-occurrence constraints using pragmas rather than trying to put it directly into the language. Jim From nobody Tue Jun 30 18:13:32 2020 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 0473C3A085F; Tue, 30 Jun 2020 18:13:31 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1_cm69fGMoq; Tue, 30 Jun 2020 18:13:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5F43A085C; Tue, 30 Jun 2020 18:13:29 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 18:13:23 -0700 From: Jim Schaad To: 'Mike Jones' , CC: References: In-Reply-To: Date: Tue, 30 Jun 2020 18:13:22 -0700 Message-ID: <03c801d64f44$d265ddb0$77319910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQG9hUW0rmWg4KI81Ec+8sUnWhASEwN/3HsqqQd+k7A= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:13:31 -0000 > -----Original Message----- > From: Mike Jones > Sent: Tuesday, June 30, 2020 5:41 PM > To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Hi Jim, > > I've applied these changes in https://tools.ietf.org/html/draft-ietf-cbor-date- > tag-02. > > Thanks again, > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 12, 2020 11:52 AM > To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Thanks for your review, Jim. My replies are inline below... > > Is it time to start WGLC so others also get their reviews in? I'll note that the > IANA registrations have already occurred at > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. > > -----Original Message----- > From: Jim Schaad > Sent: Thursday, June 11, 2020 11:48 AM > To: draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: Review draft-ietf-cbor-date-tag-01 > > * Is there any chance that you can upgrade to using the v3 of xml2rfc schema? > If not then there is not an issue as the RFC Editor will do it. > > I haven't really learned all the ins and outs of the new syntax yet, so I'd have > more confidence with the RFC Editor doing it correctly than me. > > * Introduction: I prefer the abstract form of /date but not a time/date without > a time/ > > I agree and will make this change in the next published draft. > > * While this is something that is clear to me, I got a recent comment when I > suggested that this be used elsewhere of, "But how does this work with time > zones?". Based on that I think that there needs to be some text about why time > zones are not of interest here. > > Agreed and will do. > > * Section 3- I think that the second paragraph would be wise to distinguish > between a point in time and a date when looking at access control decisions. > > I understand your point in general. Is there particular text that you'd suggest > that I incorporate? No I don't have any text in mind. Jim > > Jim > > Thanks again, > -- Mike > From nobody Tue Jun 30 18:43:01 2020 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 1691A3A08B2; Tue, 30 Jun 2020 18:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hp8UCHfUIYf; Tue, 30 Jun 2020 18:42:57 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640107.outbound.protection.outlook.com [40.107.64.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A083C3A08BD; Tue, 30 Jun 2020 18:42:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mCoFQbJvDN/S5WmsFqKREYc3NFrDYMPc2NjcpBTB/JWBFDJWacLee9nnupzAKc7teTpYLzBDmrGoFydM0kRKpXonAwNLiQ+1KsBXgrjpFFEylWxi9Uv8rkyarZgFzmWxLG6MPMT44LMQivtfNL0rim0Ub4Hd++ASYaZuHSELzzHEK8YibfGvdLehqkn+F/z9NIesG9XiGHlTjD7Y5GGo4KHKchLf1ofOXxJZW1TgfO7RzgFiMzaheXX82OwUN1Or14wDLZENGsU9c0h89Lxfqh0a58T3uHxgVvrc/wADzR9qjtm5Mji97M4eV7XLYXlseVavUZaVUbVScOpqkpfb6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RNGaTXTfWWPGSmq8MPHqYUJcD1Uy2a88zZhuIRJbENQ=; b=NX/O++dpcS27jFOy6ZRxQWs1Z7noN/VJMG5HgagpnOXk/SThRck6+TmDnFVWtWARO5w4q1bHd//nTYpjH6MYn+K2V02PaLIt38zVzg7AGsMeNRPhxFeWannKn2i6eftiHDcDI4+I4pD+iVtuQXhbnuNcNTgTjM+W7vZN22orjlkTh0FiIvVrk2QGE/N4wLP2hU3sTlzOETnPJp7pM2n2KeJ/VdwTgyCtGC5KOK0eFA4fibFkgH1PXVT1qDKTrxkwHGpghHYmU64IFrf/KIxvmPBtGTl8Xi+W0thcR2BwVuWgUvs152k24v2EV5LvGLO+OpxCHIEhtaewj7SxTvfkIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RNGaTXTfWWPGSmq8MPHqYUJcD1Uy2a88zZhuIRJbENQ=; b=bUcbQzJ+EgAlBQY763c+/7Tvvo01gM44WSGgzl+Ehf4zid+VhRcbsU8PyIcTOuVXWuhOj040eCw/jypmpvoWs8bKgiFswxsuS0SRNqEy90HG8EeJFVzgYJRqdMnnbqDKuwkKe8OtopmSNMevbXiv/WfdbavURmUxvKFnIe+8SVQ= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0727.namprd00.prod.outlook.com (2603:10b6:610:ad::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3184.0; Wed, 1 Jul 2020 01:42:52 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::a9e4:b059:3b7e:301d%8]) with mapi id 15.20.3190.000; Wed, 1 Jul 2020 01:42:52 +0000 From: Mike Jones To: Jim Schaad , "draft-ietf-cbor-date-tag@ietf.org" CC: "cbor@ietf.org" Thread-Topic: Review draft-ietf-cbor-date-tag-01 Thread-Index: AQHWT0jvz8v/hxlOq0Koar6aBzZrmA== Date: Wed, 1 Jul 2020 01:42:52 +0000 Message-ID: References: , <03c801d64f44$d265ddb0$77319910$@augustcellars.com> In-Reply-To: <03c801d64f44$d265ddb0$77319910$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-01T01:42:21.4713791Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 36ef030f-6332-46ef-367c-08d81d6011da x-ms-traffictypediagnostic: CH2PR00MB0727: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g2/othxFuM2B1BA/kPLKi52y22d3r2DGw3EC0ys0niEXGLqTk8VcrQCWc6ki9pd+djIAqitv7Uh0Sb655nonNPX7EH7KiSbcIs1SwLrnnrSYMXS/I1uro1GxISAAH72wa+s4BZuA/hr0OaRHwyr+taaYrES1Y10TDZRgLHfjJZygWamBJq/ulg9Ock+L1Hx77ZW7MKjLq96zBL6g7gVm9orladQ1cV1eaNxWc5Zrq8SIXSEzPBO3kCW/zZ7serYmRD/mZ9t2296089GRMU53Eke1fXJ6QzG2d8n9PO3p1MrFNkitLeDlCBD/4VzRi91o/rmLaWKiPv1ZnOhojildkjOk+ZHYEi4dQqaCpEkltvyRc7s54SA35lzXWlexpfax3TGJV0/AW6E9Staw9y+XZw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(396003)(346002)(376002)(91956017)(76116006)(478600001)(8676002)(82960400001)(86362001)(186003)(82950400001)(2906002)(10290500003)(55016002)(5660300002)(52536014)(8936002)(6506007)(66556008)(64756008)(7696005)(66446008)(66476007)(66946007)(33656002)(26005)(166002)(9686003)(83380400001)(71200400001)(316002)(966005)(53546011)(110136005)(8990500004)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HlKyCxbN5POR9mc63Wb3Rlla6SpDsf7LQZ5/kyxbGXNrLuQZcPupiH1TnWKKtJMuf+9g6VRIliKIRP5lKnxu4IQ5JeR/1hyZpNGTT67al4w1Lnqx/c0IBWRm9S7fxWkaFnz5VRZYZbjI5WFsGXVCGT7R1JCvf5mKiuTaCy9fENfm8r55bqwms4R9aQSApNnuXKWvegR3Wr2m1MJuU+NqhxAOms7w1kad9rLsqNAfFNUyy9YcKXTl7WsKvg1bOgSALlGHJX0REH877l9MRSe6v4J5EQLLbQj5KBXQWlXaAtv7Q/gFhWzY2qPdtybCUMCUF12+QGOsfgeMVltjHt59Gk/f7umaaN7GOfroL7qdz4/oPuTOT8Xt5RAFegretz7jxKc6mju2D5ZOnX2PQ4lPKJTnNIcbDMjm4gau7I0KVVoLLs6SvmfPl+rBs2tKf/QLfcOIqWWh2PtFhOXm/vVJBlfbEThPExUA8l1qp/b07rg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679708DDDC6E04BC0D8A3E6F56C0CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36ef030f-6332-46ef-367c-08d81d6011da X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 01:42:52.4911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0/jdw2ZM5NK89l17bmMGdPuonJ+EC6Oq7W1jtGOTpS5jCU+ZIzUTiJOfQJkiWcTeAdxwBNK7DJgnaGBIO/Ewgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0727 Archived-At: Subject: Re: [Cbor] Review draft-ietf-cbor-date-tag-01 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:43:00 -0000 --_000_CH2PR00MB0679708DDDC6E04BC0D8A3E6F56C0CH2PR00MB0679namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I created text. -- Mike ________________________________ From: Jim Schaad Sent: Tuesday, June 30, 2020 6:13:22 PM To: Mike Jones ; draft-ietf-cbor-date-tag@ietf= .org Cc: cbor@ietf.org Subject: [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01 > -----Original Message----- > From: Mike Jones > Sent: Tuesday, June 30, 2020 5:41 PM > To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.or= g > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Hi Jim, > > I've applied these changes in https://tools.ietf.org/html/draft-ietf-cbor-date- > tag-02. > > Thanks again, > -- Mike > > -----Original Message----- > From: Mike Jones > Sent: Friday, June 12, 2020 11:52 AM > To: Jim Schaad ; draft-ietf-cbor-date-tag@ietf.or= g > Cc: cbor@ietf.org > Subject: RE: Review draft-ietf-cbor-date-tag-01 > > Thanks for your review, Jim. My replies are inline below... > > Is it time to start WGLC so others also get their reviews in? I'll note that the > IANA registrations have already occurred at > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml. > > -----Original Message----- > From: Jim Schaad > Sent: Thursday, June 11, 2020 11:48 AM > To: draft-ietf-cbor-date-tag@ietf.org > Cc: cbor@ietf.org > Subject: Review draft-ietf-cbor-date-tag-01 > > * Is there any chance that you can upgrade to using the v3 of xml2rfc schema? > If not then there is not an issue as the RFC Editor will do it. > > I haven't really learned all the ins and outs of the new syntax yet, so I'd have > more confidence with the RFC Editor doing it correctly than me. > > * Introduction: I prefer the abstract form of /date but not a time/date without > a time/ > > I agree and will make this change in the next published draft. > > * While this is something that is clear to me, I got a recent comment whe= n I > suggested that this be used elsewhere of, "But how does this work with time > zones?". Based on that I think that there needs to be some text about wh= y time > zones are not of interest here. > > Agreed and will do. > > * Section 3- I think that the second paragraph would be wise to distinguish > between a point in time and a date when looking at access control decisions. > > I understand your point in general. Is there particular text that you'd suggest > that I incorporate? No I don't have any text in mind. Jim > > Jim > > Thanks again, > -- Mike > --_000_CH2PR00MB0679708DDDC6E04BC0D8A3E6F56C0CH2PR00MB0679namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I created text.

-- Mike

From: Jim Schaad <ietf@a= ugustcellars.com>
Sent: Tuesday, June 30, 2020 6:13:22 PM
To: Mike Jones <Michael.Jones@microsoft.com>; draft-ietf-cbor-= date-tag@ietf.org <draft-ietf-cbor-date-tag@ietf.org>
Cc: cbor@ietf.org <cbor@ietf.org>
Subject: [EXTERNAL] RE: Review draft-ietf-cbor-date-tag-01
 


> -----Original Message-----
> From: Mike Jones <Michael.Jones@microsoft.com>
> Sent: Tuesday, June 30, 2020 5:41 PM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-cbor-date-ta= g@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: Review draft-ietf-cbor-date-tag-01
>
> Hi Jim,
>
> I've applied these changes in
https://tools= .ietf.org/html/draft-ietf-cbor-date-
> tag-02.
>
>            = ;            &n= bsp;       Thanks again,
>            = ;            &n= bsp;       -- Mike
>
> -----Original Message-----
> From: Mike Jones
> Sent: Friday, June 12, 2020 11:52 AM
> To: Jim Schaad <ietf@augustcellars.com>; draft-ietf-cbor-date-ta= g@ietf.org
> Cc: cbor@ietf.org
> Subject: RE: Review draft-ietf-cbor-date-tag-01
>
> Thanks for your review, Jim.  My replies are inline below...
>
> Is it time to start WGLC so others also get their reviews in?  I'= ll note
that the
> IANA registrations have already occurred at
> https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml.
>
> -----Original Message-----
> From: Jim Schaad <ietf@augustcellars.com>
> Sent: Thursday, June 11, 2020 11:48 AM
> To: draft-ietf-cbor-date-tag@ietf.org
> Cc: cbor@ietf.org
> Subject: Review draft-ietf-cbor-date-tag-01
>
> * Is there any chance that you can upgrade to using the v3 of xml2rfc<= br> schema?
> If not then there is not an issue as the RFC Editor will do it.
>
> I haven't really learned all the ins and outs of the new syntax yet, s= o
I'd have
> more confidence with the RFC Editor doing it correctly than me.
>
> * Introduction:  I prefer the abstract form of /date but not a ti= me/date
without
> a time/
>
> I agree and will make this change in the next published draft.
>
> * While this is something that is clear to me, I got a recent comment = when
I
> suggested that this be used elsewhere of, "But how does this work= with
time
> zones?".  Based on that I think that there needs to be some = text about why
time
> zones are not of interest here.
>
> Agreed and will do.
>
> * Section 3- I think that the second paragraph would be wise to
distinguish
> between a point in time and a date when looking at access control
decisions.
>
> I understand your point in general.  Is there particular text tha= t you'd
suggest
> that I incorporate?

No I don't have any text in mind.

Jim

>
> Jim
>
>            = ;            &n= bsp;       Thanks again,
>            = ;            &n= bsp;       -- Mike
>


--_000_CH2PR00MB0679708DDDC6E04BC0D8A3E6F56C0CH2PR00MB0679namp_-- From nobody Tue Jun 30 20:54:08 2020 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 973BF3A0AFD for ; Tue, 30 Jun 2020 20:54:06 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b4Y1jzRaa7u for ; Tue, 30 Jun 2020 20:54:03 -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 66BEA3A0A79 for ; Tue, 30 Jun 2020 20:54:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A60A1389BA; Tue, 30 Jun 2020 23:51:14 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SJVPiwIaMbjV; Tue, 30 Jun 2020 23:51:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2923C389B2; Tue, 30 Jun 2020 23:51:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5EF3E1F9; Tue, 30 Jun 2020 23:54:00 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: cbor@ietf.org In-Reply-To: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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 Module Design X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 03:54:07 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > 1. What is the naming scheme to be used? Both XML Schema and ASN.1 use > unique identifiers for a module. The problem with this approach is that a > revised module has a new identifier even if all of the changes were > preserving of the old module. This can also present problems if two > different versions of the same module are used as it can be difficult to > know which version of a module is being provided. Doesn't the version problem also include the "DLL hell" problem? That is: module A includes module B.1 which includes C.1 A includes module D.1 which includes C.2 and who knows if C.1 and C.2 can be used at the same time? So I totally agree that this is a problem. > I think therefore it > would be nice to have a naming system that recognizes version numbers, but > can be used with a "latest version" mode. One possible way to do this would > be to use a query parameter to get a specific version of a module while > without the query parameter the compiler grabs the most recent version it > has. I think that this is probably a very elegant solution. > 2. Do want the naming scheme to be used to access a module name from the > web, and to create a server to host all of the IETF based CDDL modules? A think that I dislike about the ENTITY stuff in XML is that the URLs are way too specific. Do you want avoid that? Will it be some URN space? > 3. For any number of reasons we need to be able to state that some symbols > are going to be imported from a different module. There are some issues > around doing a couple of other things: > * If all symbols are imported then you either need to have a module based > naming system or you need to ensure that there are no collisions. > * If only specific symbols are imported, then they could either be a) made > to be unique by renaming or b) made to be unique in the current module > simply by how the module is written Can you give an example of (b)? I think that Python mostly got this process right. > 4. ASN.1 has a method to say that only specific symbols can be exported > from a module. I have never used this capability and I am not clear that it > would be useful to have here. Should we support it anyway? No. It just leads to stupid work arounds. _ for things that should not be exported, but not enforced. > 5. How should the system be setup to be able to recognize this capability. > The suggestion in the freezer document currently is to use a pragma system. > Introducing a pragma system can easily be seen as a step to allow for > compilers of CDDL to be written. The A2C compiler that I wrote used --# > and #-- as the start and stop delimiters for pragmas as "--" is the > start/stop comment character. (ASN.1 is not line based so there is no > comment till a return.) A similar approach can easily be used here. I prefer that the statement not be a pre-processor-like hack. > 6. If we use a pragma naming system, do we want to setup in advance for it > to have namespaces so that a single module could be used with different > compilers. I ended up using a different string than the OSS compiler did > ("--<" ">--") to be able to do this but having a namespace could also > support this. I don't understand. > 7. What set of pragmas are we looking at to start with. XML Schema has > some attributes that can be used for controlling the compiler. One of this > is a location hint attribute which can be used for giving alternate > locations to use for finding a module (such as a location on my machine). > There might be some other pragmas that might be useful to specify as well. > It might be easier to specify co-occurrence constraints using pragmas rather > than trying to put it directly into the language. This is useful at the top-level file. Particularly for a group of people who are working together. For "location on my machine", I think that I'd rather be providing a command flag, but I don't object to having ../.. paths or https://my.little.server.example/ in a file. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl78CNgACgkQgItw+93Q 3WXw/QgAulaaxrCUkKbUoD2jbN70//dOje5Crg1N+3G73ImUdpvMBkBcvHESHvpp X6JwlbQDIv7CVqEE1q8Bgoim3HthDCewv5KBEmH5cCamLhguiaKnHUQojU6iiMZv 77+C2TGP3BzkiYVMLCCSCaHnrqlAh5YjqZn+e58RrJaksN7HoWr0CzFe54Pu79oP 66axNv5HQsuRCMyfNfHfUERzpcnR+F/3wgjWf6Hy4nfP2ANZnmDAtpc/xFyFhtaq ooWOOzqLNpP5kGlC1XxKka/W9jhMu90tCrDlyyBExEOA0q9EI8gXzq2WdCHyM935 a7ZQgjA3spRF1vtkzImXvOo9xa+8EA== =nyLd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 30 22:17:06 2020 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 370AE3A0D04 for ; Tue, 30 Jun 2020 22:17:05 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IeRwk2aj3tf for ; Tue, 30 Jun 2020 22:17:03 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EA93A0D03 for ; Tue, 30 Jun 2020 22:17:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 22:16:38 -0700 From: Jim Schaad To: 'Michael Richardson' CC: References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <24433.1593575640@localhost> In-Reply-To: <24433.1593575640@localhost> Date: Tue, 30 Jun 2020 22:16:35 -0700 Message-ID: <03db01d64f66$cc797a20$656c6e60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ5T9b3i55/+CwwqSdD3kqEjEw/wAJfVF68p5kow9A= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] CDDL Module Design X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 05:17:05 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Tuesday, June 30, 2020 8:54 PM > To: Jim Schaad > Cc: cbor@ietf.org > Subject: Re: [Cbor] CDDL Module Design > > > Jim Schaad wrote: > > 1. What is the naming scheme to be used? Both XML Schema and ASN.1 > use > > unique identifiers for a module. The problem with this approach is that a > > revised module has a new identifier even if all of the changes were > > preserving of the old module. This can also present problems if two > > different versions of the same module are used as it can be difficult to > > know which version of a module is being provided. > > Doesn't the version problem also include the "DLL hell" problem? > That is: > module A includes module B.1 which includes C.1 > A includes module D.1 which includes C.2 > > and who knows if C.1 and C.2 can be used at the same time? > > So I totally agree that this is a problem. > > > I think therefore it > > would be nice to have a naming system that recognizes version numbers, > but > > can be used with a "latest version" mode. One possible way to do this > would > > be to use a query parameter to get a specific version of a module while > > without the query parameter the compiler grabs the most recent version it > > has. > > I think that this is probably a very elegant solution. > > > 2. Do want the naming scheme to be used to access a module name from > the > > web, and to create a server to host all of the IETF based CDDL modules? > > A think that I dislike about the ENTITY stuff in XML is that the URLs are way > too specific. Do you want avoid that? Will it be some URN space? I was thinking about the question of doing a URN instead of a URL - hence the term naming scheme. The interesting question is how should the naming be done and what short of mapping is needed. One of the nice things about DOIs is that they can be used as an indirect reference with a well known server to get actual URLs > > > 3. For any number of reasons we need to be able to state that some > symbols > > are going to be imported from a different module. There are some issues > > around doing a couple of other things: > > * If all symbols are imported then you either need to have a module based > > naming system or you need to ensure that there are no collisions. > > * If only specific symbols are imported, then they could either be a) made > > to be unique by renaming or b) made to be unique in the current module > > simply by how the module is written > > Can you give an example of (b)? > I think that Python mostly got this process right. (b) is just - don't define any conflicts between what I am importing and what I have written in the text. If I am going to use COSE_Signed as an import, then I really should define a different symbol in the current CDDL file by that name. > > > 4. ASN.1 has a method to say that only specific symbols can be exported > > from a module. I have never used this capability and I am not clear that it > > would be useful to have here. Should we support it anyway? > > No. It just leads to stupid work arounds. > _ for things that should not be exported, but not enforced. I tend to agree with this. One of the interesting questions would be transitive imports though. If module A imports COSE_Signed from module B can module B import COSE_Signed from module B or must it reference module A. I remember the first time I figured out that ASN.1 allows this and to be frank I found it somewhat irritating. It does allow moving symbols between modules, but that has the potential to break other modules suddenly. > > > 5. How should the system be setup to be able to recognize this capability. > > The suggestion in the freezer document currently is to use a pragma > system. > > Introducing a pragma system can easily be seen as a step to allow for > > compilers of CDDL to be written. The A2C compiler that I wrote used --# > > and #-- as the start and stop delimiters for pragmas as "--" is the > > start/stop comment character. (ASN.1 is not line based so there is no > > comment till a return.) A similar approach can easily be used here. > > I prefer that the statement not be a pre-processor-like hack. The interesting question then, is how much do we want to change the CDDL language. If we do pragmas this is a standalone document. If we do changes in the grammar then it is harder to make this standalone. > > > 6. If we use a pragma naming system, do we want to setup in advance for > it > > to have namespaces so that a single module could be used with different > > compilers. I ended up using a different string than the OSS compiler did > > ("--<" ">--") to be able to do this but having a namespace could also > > support this. > > I don't understand. Suppose I write a CDDL compiler - called my_great_cddl_compiler and Carsten writes one called no_so_good_cddl_compiler. I could reference pragmas as ME:UseInt32 and CB:UseInt32 as separate pragmas in the same file and each compiler would recognize that one that it implements and do the right thing (which is to use some int sized at least 32 bits?) They could have different behavior for the same name. > > > 7. What set of pragmas are we looking at to start with. XML Schema has > > some attributes that can be used for controlling the compiler. One of this > > is a location hint attribute which can be used for giving alternate > > locations to use for finding a module (such as a location on my machine). > > There might be some other pragmas that might be useful to specify as > well. > > It might be easier to specify co-occurrence constraints using pragmas > rather > > than trying to put it directly into the language. > > This is useful at the top-level file. > Particularly for a group of people who are working together. > For "location on my machine", I think that I'd rather be providing a command > flag, but I don't object to having ../.. paths or https://my.little.server.example/ > in a file. Another one at the top level might be to use one of the more interesting things that the OSS compiler does is to allow one to say - This is the list of symbols to emit which can be used rather than either emit everything or emit the first symbol in the file which made me do some really strange things in the COSE CDDL. Jim > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- From nobody Tue Jun 30 22:33:34 2020 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 7E7AC3A0064 for ; Tue, 30 Jun 2020 22:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHYP9k_uiXNB for ; Tue, 30 Jun 2020 22:33:29 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDB33A0063 for ; Tue, 30 Jun 2020 22:33:28 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xVJ46Sd7zyX5; Wed, 1 Jul 2020 07:33:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> Date: Wed, 1 Jul 2020 07:33:24 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 615274404.442688-cad5d00603ca0632db8d2c8f702f10f8 Content-Transfer-Encoding: quoted-printable Message-Id: <58F93C93-9EC6-465E-B421-12AA69F17CAF@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 05:33:33 -0000 Hi Jim, we have had a long discussion about namespacing in the SDF work, and = came up with: = https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html#name-names-and-names= paces Now SDF is not CDDL, but I think there are lessons to be learned. For a while, we were thinking about using URIs to find referenced parts = of a specification. This is comparable to the way Java does its module = naming; you essentially need to put the code into the place that is = implied by its name. Instead, we have decided to go for a push model, which is essentially = the way C++, C#, and other languages maintain their namespaces. A = module declares into which namespaces its names go. There is no = automatic finding of modules, but there also is no pain about who can = contribute to a namespace. > On 2020-07-01, at 02:52, Jim Schaad wrote: >=20 > Here is a topic that we can potentially discuss tomorrow if there is = extra > time on the agenda. >=20 > When looking at a CDDL module design, there are a set of questions = that I > think need to be addressed: >=20 > 1. What is the naming scheme to be used? Both XML Schema and ASN.1 = use > unique identifiers for a module. The problem with this approach is = that a > revised module has a new identifier even if all of the changes were > preserving of the old module. This can also present problems if two > different versions of the same module are used as it can be difficult = to > know which version of a module is being provided. I think therefore = it > would be nice to have a naming system that recognizes version numbers, (I think you are talking about revision numbers. Version numbers are often not what one wants; instead one should use = feature identifiers.) > but > can be used with a "latest version" mode. One possible way to do this = would > be to use a query parameter to get a specific version of a module = while > without the query parameter the compiler grabs the most recent version = it > has. >=20 > 2. Do want the naming scheme to be used to access a module name from = the > web, and to create a server to host all of the IETF based CDDL = modules? That was what we decided we didn=E2=80=99t want to do in SDF. > 3. For any number of reasons we need to be able to state that some = symbols > are going to be imported from a different module. =20 Note how C++ doesn=E2=80=99t really do that. (Well, if you declare a name and don=E2=80=99t define it, it needs to be = external.) > There are some issues > around doing a couple of other things: > * If all symbols are imported then you either need to have a module = based > naming system or you need to ensure that there are no collisions. I would like to separate the external naming system from the internal = one we use in a spec. Note how a spec already today uses symbols from the prelude and from the = spec itself. (This of course works =E2=80=9Cautomagically=E2=80=9D only = because the prelude is fixed and you simply cannot use the symbols that = the prelude squats on.) > * If only specific symbols are imported, then they could either be a) = made > to be unique by renaming or b) made to be unique in the current module > simply by how the module is written Yes. > 4. ASN.1 has a method to say that only specific symbols can be = exported > from a module. I have never used this capability and I am not clear = that it > would be useful to have here. Should we support it anyway? I think there might be a place for an advisory-level setting (as in = =E2=80=9Cthese names will normally be imported if this module is = imported whole-sale=E2=80=9D). Experience shows that there are good = reasons to violate any =E2=80=9Cencapsulation=E2=80=9D attempt, so I = would not disallow importing further names from a module explicitly. > 5. How should the system be setup to be able to recognize this = capability. > The suggestion in the freezer document currently is to use a pragma = system. > Introducing a pragma system can easily be seen as a step to allow for > compilers of CDDL to be written. The A2C compiler that I wrote used = --# > and #-- as the start and stop delimiters for pragmas as "--" is the > start/stop comment character. (ASN.1 is not line based so there is no > comment till a return.) A similar approach can easily be used here. This is the approach I would prefer. However, there also is semantics imparted by using a symbol. In actual CDDL usage, the symbols used become annotations in the = post-validation instance. These annotations will need to be namespaced, = and possibly be linked to RDF names (which are URIs not intended for = dereferencing). > 6. If we use a pragma naming system, do we want to setup in advance = for it > to have namespaces so that a single module could be used with = different > compilers. I ended up using a different string than the OSS compiler = did > ("--<" ">--") to be able to do this but having a namespace could also > support this. Indeed, we could play around with more than one module/namespace = management system, as long as there is a way to generate a basic CDDL = specification from each. > 7. What set of pragmas are we looking at to start with. XML Schema = has > some attributes that can be used for controlling the compiler. One of = this > is a location hint attribute which can be used for giving alternate > locations to use for finding a module (such as a location on my = machine). Tempting, but this leads us back into pull land. > There might be some other pragmas that might be useful to specify as = well. > It might be easier to specify co-occurrence constraints using pragmas = rather > than trying to put it directly into the language. I think that all constraints need to be part of the language. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 23:31:51 2020 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 BED5D3A084A for ; Tue, 30 Jun 2020 23:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGUMTgHiFzWg for ; Tue, 30 Jun 2020 23:31:47 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180663A084B for ; Tue, 30 Jun 2020 23:31:46 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xWbP1JcyzyWw; Wed, 1 Jul 2020 08:31:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <58F93C93-9EC6-465E-B421-12AA69F17CAF@tzi.org> Date: Wed, 1 Jul 2020 08:31:44 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 615277904.801942-b67c6fe1bdc1d374c5e1a7e3514c59fa Content-Transfer-Encoding: quoted-printable Message-Id: <5A3152DB-7A16-4831-8508-FD4AEF2F415B@tzi.org> References: <03c701d64f41$e1763fa0$a462bee0$@augustcellars.com> <58F93C93-9EC6-465E-B421-12AA69F17CAF@tzi.org> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL Module Design X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 06:31:50 -0000 So here are a few terms (and items of thought) that I would like to = propose as a ground structure: Symbols: Rule names as defined in RFC 8610. This namespace is used = within a specification and should stay reasonably clean of = considerations on where the name came from. E.g., a CDDL specification = today can use symbols from prelude and from itself. External names: Names that go into a larger name space, some of which = may be global. A CDDL spec can import definitions associated with an = external name (mapping that into symbols local to the spec) and export = into (make its symbols available in) the global namespace. =20 Global namespace: external names that are curated in such a way that = there are no conflicts. It probably makes sense to allow for = =E2=80=9Cecosystem namespaces=E2=80=9D, i.e., a way to partition off = subspaces of the global namespace that can be used in an SDO without the = need for coordination with others. Revision: a specific instant in the progression of a specification. = Revisions may or may not semantically differ (a new revision could have = a better copyright statement, a new license, better acknowledgements, = reordered rules, etc. without any semantic implications). Module reference: a name that, at a particular point in time, identifies = a set of specifications that make up a module (if that term makes = sense). Module references are intended to allow for evolution of the = modules; they may also be frozen to specific revisions (which doesn=E2=80=99= t allow for bug fixing). Module references need to cope with the fact = that a specific implementation may be bound to a state of the module = that is earlier in time than the one considered most recent by a = contributing entity; whether that state is compatible with the desired = use of the module will have to be expressed in the module reference = (e.g., by using feature identifiers). Feature name: Name for a (potentially upwardly compatible, potentially = not) state of a module that incorporates certain additions/changes. A = feature name can take the form of a version (=E2=89=A0 revision), or it = can be more granular. Semantic name: a name that interfaces with the world outside CDDL, e.g., = an RDF class name. These often will be URIs. Often, a symbol in a = specification will be annotated with a semantic name; this is of no = consequence to the structural semantics of CDDL, but might turn up in a = post-validation instance. (It is not clear to me whether there needs to be a shortcut between = semantic names and external names =E2=80=94 I=E2=80=99d like to keep = them separate for now.) Note that keys (the name part of a name/value pair) in groups are often = used as abbreviated semantic names (whether they are ignored at the CDDL = level as in arrays or &-choices, or actually used as map keys). There = probably needs to be some way to map these to fully fleshed out semantic = names. (Note that these keys often are written as barewords, so they = may look like symbols, but aren=E2=80=99t!) Gr=C3=BC=C3=9Fe, Carsten