From nobody Wed Apr 8 02:37: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 25D703A0F7D; Wed, 8 Apr 2020 02:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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=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 75-_3QwG-AuE; Wed, 8 Apr 2020 02:37:42 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70049.outbound.protection.outlook.com [40.107.7.49]) (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 03C233A0F7C; Wed, 8 Apr 2020 02:37:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CHW3iR9RLV7t2ZXX9234ysoqhsoZxB9t10HVu+LnAgf7EG+Jrz1hS8J/UfFL6b84bgV9w51rM6YdpfrlW2YYf4dcqK74mDIn3mIQ+weHH25fiFu09xeysnGaWGUjNXHKsRtyr0LsQLfNyyoZGylybSx3Krce2HpZ905OjLfYyAM742I1zXsiKgeOr/UF0kazBnqgpKY5K1yomI2Pa365EHIVF0ANNtHL0XAMIs1im6xiHqfKYW1zYt9GSk+H82xVCl1CVYaEdGStIiZT7fd39bhjwv1e8YCfUNZyRWfudbwklhd4Lp/LM/DV9pwDrtIhF1ISemuUn6sUCm7bTz+YWw== 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=fEIbl/VKi0qKxcQfoLHcIXD4+x9rgzWDLynWCRhFMSs=; b=Xy6i7XmBEsU1zy++CEIyB5h2FYrse31knETILh5X5FW6pDmDL7AtSnDIMAe+wDMlKRHTAvB5SKIFGcc1x70pF4N9hUkasjNoR5G0DAPhJxRf9Av1UPRKpa9XC8og8p77/P/OMrMy0X0EvSxRN1Q0qmanjK/EjjuMIJVvscCCqP2RE6Ciwq8KfUwKbtR9PQauQBdmXOv5KnoxlNi/Mwy9DA5Y/ulTebPsdfvpb7/xSSaL45mmGF13VWqqFj7Cy2KFsgciBvrngYJlaQ/HYvDYaHzxzQp4rlsHpUmD0IfZtrDMzh/CwBjKXjhV00NlkDAmHr8wI0JqrzNsnHBMBzBl/g== 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=fEIbl/VKi0qKxcQfoLHcIXD4+x9rgzWDLynWCRhFMSs=; b=XBSik9AjXHsnxIhIJwkcRDXVR+KUiNHx9MJ/EXyx69XUYfI8ObbtxGO8fy2Nufs4s2//xlakPfKVj/xZxe6vfU73VyofkozJXGy6Q7i+GFFyKM0G4Tl6fU1iH+MK9+ZnPbtt1i1gg43K5kQlEFKzERj2lRSza6Dv+T31H729gHE= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 8 Apr 2020 09:37:36 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::94be:1ea8:6fcc:2fc2]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::94be:1ea8:6fcc:2fc2%6]) with mapi id 15.20.2900.015; Wed, 8 Apr 2020 09:37:36 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" , "cbor-ads@ietf.org" Thread-Topic: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-08 Thread-Index: AQHV9+NsI9Y7zbBInkSzDh0fx42cYqhvRGuA Date: Wed, 8 Apr 2020 09:37:36 +0000 Message-ID: <508418CF-5713-4954-8223-F1D9FE83170C@ericsson.com> References: <158395833747.1666.1343907101806680235@ietfa.amsl.com> In-Reply-To: <158395833747.1666.1343907101806680235@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70f19070-46f6-437d-777d-08d7dba078cd x-ms-traffictypediagnostic: HE1PR0702MB3818: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0367A50BB1 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:(10009020)(4636009)(396003)(39860400002)(366004)(376002)(346002)(136003)(26005)(33656002)(2906002)(6506007)(450100002)(966005)(4326008)(6512007)(478600001)(86362001)(81166007)(6916009)(54906003)(316002)(71200400001)(66574012)(5660300002)(8676002)(2616005)(8936002)(36756003)(186003)(44832011)(6486002)(16799955002)(81156014)(76116006)(64756008)(66946007)(66556008)(66446008)(66476007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XIV4kKRWQtvbGwPKx+33vIJQBZfzXouSmvVIVnxF8J8AuHTAuQ1IWx34bpsyJI19VlYdW+PxA9hqY7mOHfb6teaMjGWWNWPmbBzP+KSwA4fClBgS606eLdHyUd8AuIg2f7lzx+YhQCbMHLObRaScnF72C55jdJ46gy2WhgP3lwhpuhYkbl1XCKdg3p7sHWHsMKfrrT34aLa10ilGtCdYXx7a/TyeLRFQBQmuSf/eL6+8Z9Bx0CfOOsFQ7E17JsNo9EYg/ru99DUikNveCthdS/iNuFcBHmRBsfYoccfQSlqpDSk6WOS7jOmvR/2iH8Zarm2fQlYQl88gPK7NriN9dcfLWMRH+sU3C5V3GIRepRWbylT8b1KooW+1eYfBJtYjw7u0jDjea3CjctvF788jCV+1Qk2gvIYaGYfSOJa/rCu3wl6RvbyDP1/3+pEuX3PFetYhXJa05klUfXkxIhCNM2nbnV9P38j9ABcHT3D//SqJEtvZpLQbJidtFrqsk5IPBbTqZHsQOoh14JKCBOCkIw== x-ms-exchange-antispam-messagedata: Op4SKpYEljY1EHwfL+t/5/ZoMSZVYwyJ6tH3NvdGJ+EyefgHxtK8oq1lfWFItSWQh4SdVdjWCE1STczFDGmHJqDNL8dikW0l3xC/r4efBGjMaOcwL1gYJtbxYxog7PuWzAQCzp7okX5jU8+3phbRgQ== 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: 70f19070-46f6-437d-777d-08d7dba078cd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 09:37:36.3302 (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: J6tu3Vr3iL4p3wEjDlbmnUBTA3uxDxahHfXNaWvjlL46NGg1tSXUh8LmgPw2lE03DRESIfSm0idF5UM3ifMsMadmem57XIQflIBn6g/KsMvkTRLq0Xp5PzB694D2JRK7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3818 Archived-At: Subject: Re: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-08 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, 08 Apr 2020 09:37:44 -0000 SGkgYWxsLA0KDQpRdWljayByZW1pbmRlciB0aGF0IHdlIGFyZSBob2xkaW5nIG91ciBpbnRlcmlt L0lFVEYxMDcgbWVldGluZyB0b2RheS4NCg0KV2ViZXg6IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW1mMDVjNDdhOWE0MTgxNzllM2U4MTBhMTUxZGNiMjVhOQ0KRXRoZXJw YWQ6IGh0dHBzOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9ub3Rlcy1pZXRmLTEwNy1jYm9y DQpTZXNzaW9uIG1hdGVyaWFsOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv aW50ZXJpbS0yMDIwLWNib3ItMDYvc2Vzc2lvbi9jYm9yDQpKYWJiZXI6IGNib3JAamFiYmVyLmll dGYub3JnDQoNClRhbGsgdG8geW91IGxhdGVyIQ0KRnJhbmNlc2NhDQoNCu+7v09uIDExLzAzLzIw MjAsIDIxOjI3LCAiQ0JPUiBvbiBiZWhhbGYgb2YgSUVTRyBTZWNyZXRhcnkiIDxjYm9yLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiB3cm90ZToN Cg0KICAgIFRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gTWFpbnRlbmFu Y2UgYW5kIEV4dGVuc2lvbnMgKGNib3IpIFdvcmtpbmcgR3JvdXAgd2lsbCBob2xkDQogICAgYSB2 aXJ0dWFsIGludGVyaW0gbWVldGluZyBvbiAyMDIwLTA0LTA4IGZyb20gMTc6MDAgdG8gMTg6MDAg RXVyb3BlL1BhcmlzLg0KICAgIA0KICAgIEFnZW5kYToNCiAgICAoTm8gYWdlbmRhIHN1Ym1pdHRl ZCkNCiAgICANCiAgICBJbmZvcm1hdGlvbiBhYm91dCByZW1vdGUgcGFydGljaXBhdGlvbjoNCiAg ICBXZWJFeCBkZXRhaWxzIHdpbGwgYmUgc2VudCB0byB0aGUgQ0JPUiBtYWlsaW5nIGxpc3QgYmVm b3JlIGVhY2ggY2FsbC4NCiAgICANCiAgICBUaGUgQ0JPUiB3b3JraW5nIGdyb3VwIHdpbGwgaGF2 ZSBjb25mZXJlbmNlIGNhbGxzIHJ1bm5pbmcgZXZlcnkgdHdvDQogICAgd2Vla3MgdGhyb3VnaCB0 aGUgZW5kIG9mIEp1bHkgMjAyMCAodW50aWwgSUVURiAxMDgpLg0KICAgIA0KICAgIERheTogZXZl cnkgb3RoZXIgV2VkbmVzZGF5IGJlZ2lubmluZyBvbiA4IEFwcmlsDQogICAgRGF0ZXM6IDgsIDIy IEFwcjsgNiwgMjAgTWF5OyAzLCAxNyBKdW47IDEsIDE1IEp1bA0KICAgIFRpbWU6IDE3OjAwIHRv IDE4OjAwIENFVC9DRVNUDQogICAgDQogICAgV2Ugd2lsbCB1c2UgdGhlIHdvcmtpbmcgZ3JvdXAg V2ViRXggZm9yIHRoZSBjYWxscy4gVGhlIElFVEYgV2ViRXgNCiAgICBhY2NvdW50IGRvZXMgbm90 IGFsbG93IEludGVybmF0aW9uYWwgZGlhbGluZyBub3IgVVMgdG9sbCBmcmVlICgiODAwIg0KICAg IG51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhlIFdlYkV4IGFwcCB0byBjb25uZWN0IHlvdXIg ZGV2aWNlIGF1ZGlvLA0KICAgIGFuZCB0aGVyZSdzIGFsc28gdGhlIG9wdGlvbiBvZiBjb25uZWN0 aW9uIGRpcmVjdGx5IGZyb20geW91ciBicm93c2VyDQogICAgaWYgeW91ciBicm93c2VyIHN1cHBv cnRzIGl0Lg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICBDQk9SQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYm9yDQogICAgDQoNCg== From nobody Fri Apr 10 08:34: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 6BD1F3A0C52 for ; Fri, 10 Apr 2020 08:34:51 -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 ctZ3OlBUt7VI for ; Fri, 10 Apr 2020 08:34:50 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 E3A933A0C4C for ; Fri, 10 Apr 2020 08:34:49 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id f195so626494vka.4 for ; Fri, 10 Apr 2020 08:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o1kCGmMCbGwlQ+WOMayoCn279AJ8CYi32vZxA/CBCVU=; b=IAJtvlM7UT7TeZobehhKr+XbotqNdcwbPoW7RoquuE91KUvs16BuCT2TVVDHWOTE5J 9QprntVfmju6kguvBwys2M6o5YvZfeNUeWhF1PgQbMkhXzA6hu4acjGYQnvHSThTK5/B sGCZHbsyLVUq7ADKKYjaAVgfNq7ACym88p8cD1YInZ88RGOs8hzByRoIdVTIM8kAnpL2 LDcUJeTBQQdMShse/XmV30G/a4Iu3YK29cBM4DaLwtMshNvFcBXETVFv3poC457Tdyrd mQfh6X92SXGHvei84++9Vjs1cBNTueKx3+/75PQyMjAXzCLdPCXSUUvRp0UI4NcsPLVY vAgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o1kCGmMCbGwlQ+WOMayoCn279AJ8CYi32vZxA/CBCVU=; b=jefHeViYa8tuRoeYN66OCL6oYdaNfspO3oQECsBZqljDXt7ma+eGdsamQ9CxnCOJeb Wi6445g0mszNCY6tV6Jm7Fd+IBVxmqz3dByKpHnG0cj4B9fwC+idHtE4mVKpSXBW6aiq qdtzFK8Z4A6/o5mBM+udPlE5wy3yn9GWv/EpTfirpdNm8eOXmN5TQgpaaLkzvIeo2l9X kI8uacVsrcQ06kfKI5pfPaPkXkZSpP5yeYZyS54UKd0MuEvQRglZvfqWHmv9q9abSNSc WerYiCgLZsXwwh0veDQlnRHJ1chy+m/+r0NT1ouxlQ2n/2NF2cbnSWjHcwGa00MJMLiE cm8w== X-Gm-Message-State: AGi0PuZ7YiEuAlXJo776IGALTK39fUR0SZhNp1t2jGruiGJ0zLN0CM7I JbWBd9ATdtjdi2S+XPwtCubvfuLYdE5njreD+r2jnt9i X-Google-Smtp-Source: APiQypKfrAd07C2KippMpZLN0gTl9DxgST8V9CMKKramo0G8ENVcTHLtHPs3EjZs2jodJPCvy7QuZB8I4Wwjtz628Kw= X-Received: by 2002:a1f:93d4:: with SMTP id v203mr3706226vkd.78.1586532888325; Fri, 10 Apr 2020 08:34:48 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Beri Date: Fri, 10 Apr 2020 08:34:12 -0700 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000003bb51705a2f17930" Archived-At: Subject: [Cbor] Considerations for converting from other serializations formats like Protocol Buffers and FlatBuffers 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, 10 Apr 2020 15:34:51 -0000 --0000000000003bb51705a2f17930 Content-Type: text/plain; charset="UTF-8" Hello, I'm looking into a use case that would require converting data from existing systems that output in well-defined serialization formats (specifically Protocol Buffers and FlatBuffers ) to CBOR. The goal is in part to use other specifications like CoAP with this data as as well an existing implementation of CoAP. Has there been any investigation into converting to these formats? Any lessons or points to consider? I've been reading up on CDDL - might that help in implementing a conversion process? Many thanks. -- Jonathan Beri linkedin.com/in/jonathanberi --0000000000003bb51705a2f17930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm looking into a use case = that would require converting data from existing systems that output in wel= l-defined serialization formats (specifically Protocol Buffers and FlatBuffers) to CBOR. The goal is in par= t to use other specifications like CoAP with this data as as well an existi= ng implementation of CoAP.

Has there been any inve= stigation into converting to these formats? Any lessons or points to consid= er? I've been reading up on CDDL - might that help in implementing a co= nversion process?

Many thanks.

--
--0000000000003bb51705a2f17930-- From nobody Fri Apr 10 08:59: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 2D7EE3A044D for ; Fri, 10 Apr 2020 08:59:33 -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 Ytfi1G26Vquy for ; Fri, 10 Apr 2020 08:59: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 2A2793A044A for ; Fri, 10 Apr 2020 08:59:29 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48zN4J0yPWzyxG; Fri, 10 Apr 2020 17:59:28 +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: Fri, 10 Apr 2020 17:59:23 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 608227163.830824-e92c017b9760f8dac035dcd74af8c67d Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jonathan Beri X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] Considerations for converting from other serializations formats like Protocol Buffers and FlatBuffers 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, 10 Apr 2020 15:59:33 -0000 Hi Jonathan, Such a conversion is always =E2=80=9Cinteresting" because of the = different generic data models of the different data formats. CDDL essentially is used to define a subset of the generic data model of = CBOR. It also can =E2=80=9Cparse=E2=80=9D or =E2=80=9Cconstruct", so it = could be used as a front-end/back-end to such a conversion format, but = we would need a Format-X back-end/front-end as well. And some of this = will be idiomatic (e.g., very idiomatic in JSON), so you don=E2=80=99t = want to need to say the idiomatic things all the time. Some conversions = will even need computations (say, a JSON enum into a CBOR bit string). We have done something related to a conversion process (uncompressed vs. = compressed) in RFC 4997. This notation was also saddled with needing to = do its own binary decoding/encoding (which still would be useful as = another front-end/back-end of the above!), but the idea of having = statements that connect on two sides to two different worlds is = immediately applicable. SCHC = = is a contemporary attempt to do a bidirectional conversion, but it is = somewhat specialized to =E2=80=9Cpacket=E2=80=9D-type data. Note also that T2TRG has done a little work on =E2=80=9CYOUPI=E2=80=9D = , which is = another way to look at binary data. As you can see, I think some of this is research, and it borders on the = WISHI/One-data-model work that we are doing in T2TRG. I would really = like it if you could bring in your ideas there. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-10, at 17:34, Jonathan Beri wrote: >=20 > Hello, >=20 > I'm looking into a use case that would require converting data from = existing systems that output in well-defined serialization formats = (specifically Protocol Buffers and FlatBuffers) to CBOR. The goal is in = part to use other specifications like CoAP with this data as as well an = existing implementation of CoAP. >=20 > Has there been any investigation into converting to these formats? Any = lessons or points to consider? I've been reading up on CDDL - might that = help in implementing a conversion process? >=20 > Many thanks. >=20 > --=20 > Jonathan Beri > linkedin.com/in/jonathanberi > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Fri Apr 10 17:34: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 71CD53A13CC for ; Fri, 10 Apr 2020 17:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 k8N0HGSv8cAO for ; Fri, 10 Apr 2020 17:34:48 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 E65BE3A13CB for ; Fri, 10 Apr 2020 17:34:47 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id n25so3393709otr.10 for ; Fri, 10 Apr 2020 17:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H10Fh0hlk6+L65eO3WcjDKyDlkcm6yYhpTBUWDLjI5w=; b=VM04Ql5Jve0AM1XOKJzdn5rv6muXDYXE+/x9dQ7dz9I78aVGoQjgD/X4/+s/jKK6/Q nO4BbXVTPeiQc/9EDqln3liAJAKpEQ301kNf2dBpXQQ2CvTcVBTRU6u7Z6+OM8SXyhuS sPEPfKw6MvO1NNZXA0ST3++HEHYBXWRLWQZ1ghZ3z37crCv1GwYfLZBVmojDN7HuO+25 6ULrvTvSY0kei5eqtM4R3bHNCsNSCrIfUyixNX5D5HRSsWvUPOHFWPfFlCs87+m84RxQ XvdhYoYbEEBc3+nuGuii7RdY6PTv79ZO/oucZNCa6STPAtN+GihFpS/Qzbliu47uQH0z a01A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H10Fh0hlk6+L65eO3WcjDKyDlkcm6yYhpTBUWDLjI5w=; b=nuesjYi/VBzmE+6NjT2pBpafAu3fMP6Ug9vSxXq/tm3nYL0UVvucUiKcenDC0WVa2s rBjFTZo5Jj1SrXYUWcQFokAP2U2pfIzWHirs/vdQmZhW7oYAT6Gh+2pImUr/qV9DWfjJ j2EaDivunDLQB5JJKfRKx+E2tVMhkZKIGuvwdBWa9lQ60/An/gYgv5wo0LSYO71VsunL H2r0+2o5oOkFcbVeQKDenrSZw5togKN/1+tR0GzERCsTp0pHekpSWixNh2hetcEdIgM5 evuosA3+rkt1KESfFuWzTNkFSuaxO4qrnO8hIWfEVcS+bV4zjxptaHpriXsOA0zRksyZ uu6A== X-Gm-Message-State: AGi0PuZLga5zGes1sijeLVhsX1Z7us21N44G6YjsfI0oTM5lnMY5AqMQ yVHV1BAx4ewQ5Ff7UlM8qPLUYZpyKe6JX+E71iE= X-Google-Smtp-Source: APiQypLxWQ97fzP4nFxy9zXpkQlb7oEedS/XsQxCsNY5MavU8HoZ8LUQeP6uZ2chjymDwdItEsxpJ6SVFSxc9qw8p6c= X-Received: by 2002:a9d:1a3:: with SMTP id e32mr6257681ote.206.1586565286769; Fri, 10 Apr 2020 17:34:46 -0700 (PDT) MIME-Version: 1.0 From: David Kemp Date: Fri, 10 Apr 2020 20:34:35 -0400 Message-ID: To: jmberi@gmail.com, cbor@ietf.org Content-Type: multipart/alternative; boundary="00000000000054b93305a2f904d8" Archived-At: Subject: [Cbor] Considerations for converting from other serializations formats like Protocol Buffers and FlatBuffers 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, 11 Apr 2020 00:34:49 -0000 --00000000000054b93305a2f904d8 Content-Type: text/plain; charset="UTF-8" Jonathan, RFC 8477 describes interoperability across various standards, and observes that while great progress has been made standardizing network protocols, "At the application layer and at the level of solution frameworks, interoperability is not yet mature. Particularly, the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout SDOs. One common problem is the lack of an encoding-independent standardization of the information, the so-called information model." In 8477 terminology converting between data models is called "schema bridging", and the RFC describes both point-to-point and hub-and-spoke translation. I believe languages like Thrift and Protobuf can map fairly directly to an encoding-independent information model, which can then be used as the hub of an application data bridge. I'd like to see an example schema for your use case, to see how feasible it is to do lossless bidirectional conversion between it and a bridge's information model . Regards, Dave --00000000000054b93305a2f904d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jonathan,

RFC 8477 describes interoperability acros= s various standards, and observes that while great progress has been made s= tandardizing network protocols,

"At the application layer and a= t the level of solution frameworks,
=C2=A0interoperability is not yet ma= ture.=C2=A0 Particularly, the work on data
=C2=A0formats (in the form of= data models and information models) has not
=C2=A0seen the same level o= f consistency throughout SDOs.

=C2=A0One common problem is the lack = of an encoding-independent
=C2=A0standardization of the information, the= so-called information model."

In 8477 terminology converting b= etween data models is called "schema bridging", and the RFC descr= ibes both point-to-point and hub-and-spoke translation. I believe languages= like Thrift and Protobuf can map fairly directly to an encoding-independen= t information model, which can then be used as the hub of an application da= ta bridge.

I'd like to see an example schema for your use case, = to see how feasible it is to do lossless bidirectional conversion between i= t and a bridge's=C2=A0information model.

Regards,Dave
--00000000000054b93305a2f904d8-- From nobody Mon Apr 13 08:30:30 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 4356E3A1801 for ; Mon, 13 Apr 2020 08:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dx5D0MKkSJiu for ; Mon, 13 Apr 2020 08:30:16 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 6E4473A1812 for ; Mon, 13 Apr 2020 08:29:56 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id g10so3242233uae.5 for ; Mon, 13 Apr 2020 08:29:56 -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=jc7iYndLaYVa7VMPbMtrhwmBmvfb4qJwSMXPh23EiWI=; b=bg8nzIEoRzSPt5Ayeo5yFL59nhQiWkIBOf2W/M/EYbFrURolTjVRK8+II8on4JeFBL +0s6N5N0xbcpIR+zlGmcDS+2luLoi2XXcraRgNANxNboXEVFccQgIYEPY6aSR4Aaga7y z+/eyL9GvLt/aDUuA1vIYJJb+Qb+E6x5oYFHY0IX3T8iRgBN6bhvbdTzKCgzXvbMOYlN 1vy30T9JvpY4c0agLkm4JPmyS5EjLBrZVGAg6p+TB1wLHjmyjUoVXJ2zQLw7ZiUsv9sa EMpMmGHa63i9xziO2mgOg1VvLYmxc6EQuZoAE4LgEtwHjkAw1U3SaKVsOd7bCAx9RVhF w/Ww== 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=jc7iYndLaYVa7VMPbMtrhwmBmvfb4qJwSMXPh23EiWI=; b=Jeo6vP/p/5TO7UDqcX26JZIgYU/wgNaPy3w3mpzwHzBb5PIMQD6UMtZ/wm+BOwhavn THAVt5fgYV7Fa01dF4OxJvOOYQxb2Nmcrf6JQcT3lb5th6n0N9Fvme5OpAvLC+6OCZV9 EWCAZORcKTLi9kUpRq3gNAKX+1BMPPReePJpq109E1WiJ4QNJCTeSZhQZu/8bJxWjeQ9 mkZvNUDYQe1fhJBrStYNLXQYc8G8Y3Zjum0Pmli78uNLIdqQ3IsL+JgkIQlBe8lqYjjz r/crotYNe3S5aHYDQxN/Mq+x5kwUohWilAuHyfJclyy5zQlQHPoav5FDYn10dnUF2ez+ 5F/Q== X-Gm-Message-State: AGi0Pua30Lnd8eeeHn8S32LIVFovIVGjH4pqm9mWtdB0DANoxMfRwfL3 lPEKbwTxOwBxWpQUmNJxxJ7a6AXYIZsbUq6vluyphy6C X-Google-Smtp-Source: APiQypINuSQ3iqBVuMj9I5gA9dNgBV6F8f1HrUb04LaRU99dAwYSDpbClu97vyDu9FC+YmyYmx2xQPLiR/G3gB5ha6c= X-Received: by 2002:ab0:74cd:: with SMTP id f13mr11874729uaq.111.1586791789957; Mon, 13 Apr 2020 08:29:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Beri Date: Mon, 13 Apr 2020 08:29:13 -0700 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000f916c605a32dc07e" Archived-At: Subject: Re: [Cbor] Considerations for converting from other serializations formats like Protocol Buffers and FlatBuffers 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, 13 Apr 2020 15:30:27 -0000 --000000000000f916c605a32dc07e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Very helpful, thank you Cartsen! I just posted to the T2TRG. On computation - I've also noticed formats that weren't originally designed cross the open internet lack a framework for signing and encryption, like JOSE & COSE. I don't immediately see challenges when going between X and CBOR, especially if X doesn't define S&E. Anything that comes to mind? On Fri, Apr 10, 2020 at 8:59 AM Carsten Bormann wrote: > Hi Jonathan, > > Such a conversion is always =E2=80=9Cinteresting" because of the differen= t generic > data models of the different data formats. > > CDDL essentially is used to define a subset of the generic data model of > CBOR. It also can =E2=80=9Cparse=E2=80=9D or =E2=80=9Cconstruct", so it = could be used as a > front-end/back-end to such a conversion format, but we would need a > Format-X back-end/front-end as well. And some of this will be idiomatic > (e.g., very idiomatic in JSON), so you don=E2=80=99t want to need to say = the > idiomatic things all the time. Some conversions will even need > computations (say, a JSON enum into a CBOR bit string). > > We have done something related to a conversion process (uncompressed vs. > compressed) in RFC 4997. This notation was also saddled with needing to = do > its own binary decoding/encoding (which still would be useful as another > front-end/back-end of the above!), but the idea of having statements that > connect on two sides to two different worlds is immediately applicable. > SCHC < > https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-24> > is a contemporary attempt to do a bidirectional conversion, but it is > somewhat specialized to =E2=80=9Cpacket=E2=80=9D-type data. > > Note also that T2TRG has done a little work on =E2=80=9CYOUPI=E2=80=9D < > https://tools.ietf.org/html/draft-petrov-t2trg-youpi-01>, which is > another way to look at binary data. > > As you can see, I think some of this is research, and it borders on the > WISHI/One-data-model work that we are doing in T2TRG. I would really lik= e > it if you could bring in your ideas there. > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > On 2020-04-10, at 17:34, Jonathan Beri wrote: > > > > Hello, > > > > I'm looking into a use case that would require converting data from > existing systems that output in well-defined serialization formats > (specifically Protocol Buffers and FlatBuffers) to CBOR. The goal is in > part to use other specifications like CoAP with this data as as well an > existing implementation of CoAP. > > > > Has there been any investigation into converting to these formats? Any > lessons or points to consider? I've been reading up on CDDL - might that > help in implementing a conversion process? > > > > Many thanks. > > > > -- > > Jonathan Beri > > linkedin.com/in/jonathanberi > > _______________________________________________ > > CBOR mailing list > > CBOR@ietf.org > > https://www.ietf.org/mailman/listinfo/cbor > > --=20 Jonathan Beri linkedin.com/in/jonathanberi --000000000000f916c605a32dc07e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very helpful, thank you Cartsen! I just posted to the T2TR= G.

On computation - I've also noticed formats that w= eren't originally designed cross the open internet lack a framework for= signing and encryption, like JOSE & COSE. I don't immediately see = challenges when going between X and CBOR, especially if X doesn't defin= e=C2=A0S&E. Anything that comes to mind?

On Fri, Apr 10, 2020 at 8= :59 AM Carsten Bormann <cabo@tzi.org= > wrote:
Hi J= onathan,

Such a conversion is always =E2=80=9Cinteresting" because of the diffe= rent generic data models of the different data formats.

CDDL essentially is used to define a subset of the generic data model of CB= OR.=C2=A0 It also can =E2=80=9Cparse=E2=80=9D or =E2=80=9Cconstruct", = so it could be used as a front-end/back-end to such a conversion format, bu= t we would need a Format-X back-end/front-end as well.=C2=A0 And some of th= is will be idiomatic (e.g., very idiomatic in JSON), so you don=E2=80=99t w= ant to need to say the idiomatic things all the time.=C2=A0 Some conversion= s will even need computations (say, a JSON enum into a CBOR bit string).
We have done something related to a conversion process (uncompressed vs. co= mpressed) in RFC 4997.=C2=A0 This notation was also saddled with needing to= do its own binary decoding/encoding (which still would be useful as anothe= r front-end/back-end of the above!), but the idea of having statements that= connect on two sides to two different worlds is immediately applicable. SCHC <https://tools.ietf.or= g/html/draft-ietf-lpwan-ipv6-static-context-hc-24> is a contemporary= attempt to do a bidirectional conversion, but it is somewhat specialized t= o =E2=80=9Cpacket=E2=80=9D-type data.

Note also that T2TRG has done a little work on =E2=80=9CYOUPI=E2=80=9D <= https://tools.ietf.org/html/draft-petrov-t2tr= g-youpi-01>, which is another way to look at binary data.

As you can see, I think some of this is research, and it borders on the WIS= HI/One-data-model work that we are doing in T2TRG.=C2=A0 I would really lik= e it if you could bring in your ideas there.

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




> On 2020-04-10, at 17:34, Jonathan Beri <jmberi@gmail.com> wrote:
>
> Hello,
>
> I'm looking into a use case that would require converting data fro= m existing systems that output in well-defined serialization formats (speci= fically Protocol Buffers and FlatBuffers) to CBOR. The goal is in part to u= se other specifications like CoAP with this data as as well an existing imp= lementation of CoAP.
>
> Has there been any investigation into converting to these formats? Any= lessons or points to consider? I've been reading up on CDDL - might th= at help in implementing a conversion process?
>
> Many thanks.
>
> --
> Jonathan Beri
> linkedin.com/in/jonathanberi
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor



--
--000000000000f916c605a32dc07e-- From nobody Mon Apr 13 08:45: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 B0A953A1864 for ; Mon, 13 Apr 2020 08:45:54 -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 QbiFItbexKCN for ; Mon, 13 Apr 2020 08:45:53 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 0ED7C3A1866 for ; Mon, 13 Apr 2020 08:45:53 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id b5so5725219vsb.1 for ; Mon, 13 Apr 2020 08:45:52 -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=p6+3EtbQSeYCdMddWTX3TgcLy9XQbTp0TP3nEt5syZk=; b=sOKAnG7WhXsRV163c0V6TRKUp8FCX5M00BJRx9kDnqBmQHrcSYRs2TtD/z5ButF/NK iC4wn4iXBk/G5I4g/eurpgAd1wSvRdFIROXSGp2mai0ygwcGwJysHZSVfzvuy0dU5s+d SIfnsAr3UZZjQLh12Izz7Lf2uCjxEV7UCSJzPEaktN7FnP5ukP8csXC1rUDvPb6W9q4Y Ll5qAqp+me5SB12rXAJL6yPGSiFNc+oSKxSG+I5N7kCE57t/x2ci25txlkHPKr9MhfjN zJIDelqVadsPrTJwGs2RoS53hq9Y8bPCRMa7kBmJWjSKQVi32IGFNCiB7INWQ+XtdyfF gf/w== 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=p6+3EtbQSeYCdMddWTX3TgcLy9XQbTp0TP3nEt5syZk=; b=nQTIxRLtg3z4hTm+FHRtHpf2GlGPNJ00EewPbo2e1mZ+h5I1VYYRBeGmP+MzsBtaRB idsQcHfZ9yDsTemgpDrN1ewWrbWe+JSwOhR2SjoTDo6vcYzrEAwCHYzxGKUk/FJxdLPO UK5Y+4XOCEcXC7fC8rGBwjUbsFVCCkfFwNuuWF9wCGSJqRTNEwHl4e3pQlLkQKMLqbTc VGdVvAyKL+92dXRRgkkTW6v7PRfw6l9bOVhwqEYg36/+enNuKNJG5edQVfq0TKypGKk4 bHwnxmf9PoDg7L07opV6UZn/bAvtAKQtnzpeFk8Qzr9its1c4htQRB1vMMOTzCPk8ftK A63Q== X-Gm-Message-State: AGi0PuZbDhKP71LIaIBHVapazKYyM//SlqX20YhBc6n2jiPCfXUTsPMR Cglt/EUBuSt1ggs0mwn4P1BNwUfl217Dtp1YaAE= X-Google-Smtp-Source: APiQypJ4OzG6jEnTFDUXeacZa1oiIdUe2pij7WsPhcQlnQ5PLaNduKK2G9CxQeBLvY/TVDzc15hU7SvX1SrFteyEo4o= X-Received: by 2002:a67:2e96:: with SMTP id u144mr1086034vsu.186.1586792751867; Mon, 13 Apr 2020 08:45:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Beri Date: Mon, 13 Apr 2020 08:45:16 -0700 Message-ID: To: David Kemp Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="0000000000004eaf2005a32dfa55" Archived-At: Subject: Re: [Cbor] Considerations for converting from other serializations formats like Protocol Buffers and FlatBuffers 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, 13 Apr 2020 15:45:55 -0000 --0000000000004eaf2005a32dfa55 Content-Type: text/plain; charset="UTF-8" Thanks David - RFC8477 has many good observations and JADN looks promising! One use case is distributing machine learning models to devices. The popular Tensorflow project has a resource-optimized version called Tensorflow Lite , which creates models using the aforementioned FlatBuffers format . Naive implementations might send a model following this schema . More advanced use cases might send compiled C/C++ for maximum efficiency, but that's beyond this discussion. On Fri, Apr 10, 2020 at 5:34 PM David Kemp wrote: > Jonathan, > > RFC 8477 describes interoperability across various standards, and observes > that while great progress has been made standardizing network protocols, > > "At the application layer and at the level of solution frameworks, > interoperability is not yet mature. Particularly, the work on data > formats (in the form of data models and information models) has not > seen the same level of consistency throughout SDOs. > > One common problem is the lack of an encoding-independent > standardization of the information, the so-called information model." > > In 8477 terminology converting between data models is called "schema > bridging", and the RFC describes both point-to-point and hub-and-spoke > translation. I believe languages like Thrift and Protobuf can map fairly > directly to an encoding-independent information model, which can then be > used as the hub of an application data bridge. > > I'd like to see an example schema for your use case, to see how feasible > it is to do lossless bidirectional conversion between it and a bridge's information > model > . > > Regards, > Dave > -- Jonathan Beri linkedin.com/in/jonathanberi --0000000000004eaf2005a32dfa55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0David - RFC8477 has many good observations and= JADN=C2=A0looks promising!

One use case is distributing= machine learning models to devices. The popular Tensorflow project has a r= esource-optimized version called Tensorflow=C2=A0Lite, which creates models using the aforementioned= =C2=A0FlatBuffers format. Naive implementations might sen= d a model following this schema. More advanced = use cases might send compiled C/C++ for maximum efficiency, but that's = beyond this discussion.

On Fri, Apr 10, 2020 at 5:34 PM David Kemp &l= t;dk190a@gmail.com> wrote:
Jona= than,

RFC 8477 describes interoperability across various standards, = and observes that while great progress has been made standardizing network = protocols,

"At the application layer and at the level of soluti= on frameworks,
=C2=A0interoperability is not yet mature.=C2=A0 Particula= rly, the work on data
=C2=A0formats (in the form of data models and info= rmation models) has not
=C2=A0seen the same level of consistency through= out SDOs.

=C2=A0One common problem is the lack of an encoding-indepe= ndent
=C2=A0standardization of the information, the so-called informatio= n model."

In 8477 terminology converting between data models is= called "schema bridging", and the RFC describes both point-to-po= int and hub-and-spoke translation. I believe languages like Thrift and Prot= obuf can map fairly directly to an encoding-independent information model, = which can then be used as the hub of an application data bridge.

I&#= 39;d like to see an example schema for your use case, to see how feasible i= t is to do lossless bidirectional conversion between it and a bridge's= =C2=A0information model.

Regards,
= Dave


--
--0000000000004eaf2005a32dfa55-- From nobody Mon Apr 13 10:14:28 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 0FA353A1B93 for ; Mon, 13 Apr 2020 10:14:26 -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 RHpIlqzVDKni for ; Mon, 13 Apr 2020 10:14:24 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 8EE213A1B8F for ; Mon, 13 Apr 2020 10:14:24 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id g24so16925vsp.8 for ; Mon, 13 Apr 2020 10:14:24 -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; bh=ToThfHZfAfZTsJmdDI/sxe1KL3q3d07qwkQ5mgAPPFA=; b=c7gkm/8KOfl7EIazISZrb7P9NrWyrHYA43RQBJsTIYmq3FI4d3Yttl0BTN17yAhOPl 7HJNstpbYXDds/t6UVPoD9Q6NooCfQ9y5UeZfS/qCbEakmWZrzwa65MfwWiOj3TAxEui A+ICrjddpj/FcVSb10ACgDMp7eC5lP4d7accUo7JUUi9sGa/e7Jd8iObtzNFdXeW5qrU DZ+SEpdj80FOTo3H8AmIUgGVfS0DmQcysIZgBQVLctnSMGfQNxDHm3f46I4UoigOJ+Kh s/9iomj4clGVn9ZRsVPMDO3uuCO4qSiA3fEmFu9AT7tnkR38vF6SL03fCNihDX757zCy bgkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ToThfHZfAfZTsJmdDI/sxe1KL3q3d07qwkQ5mgAPPFA=; b=VZLK8mhO5iF4kqGd9BEWwWTDsGq6Q7suTalDcIxmaTytOqNzsJ42GxSy/E7Fq4IPdo Nvm0fQA+5IhI9jXYbwqQ+BGhRQIFKBznZ/De/7QmcxVwmjNtDX95VyMhUI8xMRCkstDi H7gFVRm1YbzuulPcrOJRD5iQBZ1p8sZxPgOg2SEED9rKPcD69+v8EKDYaQkUjCbK0jVd jnFqsQZt8SxsiEEaQUsqFqgQYCEugBdmBMOSr3+wfOoNz404rWVJjHgZQvplJz8CGZ0S nqK4HHzXiKdC2Mwf7kUvpKipa0hcq2Oavwyw1Sxml0TFHHdkzVBnAxh/p6t2uvBoYzvS e8GA== X-Gm-Message-State: AGi0PubEcm/1o3NCjfdHG4bNij+BMoydJ2IVxYYz1FKc3sCrHPyAndE2 KyLlADRj7B96dZIY6xHN7Uk1BpHEfmGoE9hdI8I2hA== X-Google-Smtp-Source: APiQypKnzDCfauPxx4XPaYHdr2lgcE2CmwAifgnw76Wdkhyoz13zMqdmH3J2cp7qnxqYT/R9brtcSb3Z4rPYAH7bKGk= X-Received: by 2002:a67:a20f:: with SMTP id l15mr12734262vse.40.1586798063234; Mon, 13 Apr 2020 10:14:23 -0700 (PDT) MIME-Version: 1.0 References: <8dc45105cca508bc6981e0be2b709508.squirrel@www.rfc-editor.org> In-Reply-To: <8dc45105cca508bc6981e0be2b709508.squirrel@www.rfc-editor.org> From: Ira McDonald Date: Mon, 13 Apr 2020 13:14:12 -0400 Message-ID: To: cbor@ietf.org, Ira McDonald Content-Type: multipart/alternative; boundary="000000000000e3b44805a32f36d9" Archived-At: Subject: [Cbor] Fwd: [dispatch] Heads up - JSON Data Definition Format (JDDF) 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, 13 Apr 2020 17:14:26 -0000 --000000000000e3b44805a32f36d9 Content-Type: text/plain; charset="UTF-8" Hi, FYI This JDDF in the ISE appears to overlap w/ CDDL - is anyone in CBOR WG watching this one? Cheers, - Ira ---------- Forwarded message --------- From: RFC ISE (Adrian Farrel) Date: Fri, Apr 10, 2020 at 6:18 PM Subject: [dispatch] Heads up - JSON Data Definition Format (JDDF) To: Cc: Hi Dispatch, draft-ucarion-json-type-definition has been presented to the Independent Submissions Editor for publication as an RFC. During review it was suggested to me that the topic might be of sufficient interest that a WG could be formed, but there doesn't seem to be quite that level of enthusiasm. In discussing this with the ADs, they suggested I should flag this to you. I'd certainly be interested in hearing any comments, and if Dispatch wanted to take this on that would be worth knowing. Thanks, Adrian -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --000000000000e3b44805a32f36d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

FYI

=
This JDDF in the ISE appears to overlap w/ CDDL - is anyone in CBOR WG=
watching this one?

Cheers,
- Ira


---------- Forwarded message ---------
From: RFC ISE (Adrian Farrel) <rfc-= ise@rfc-editor.org>
Date: Fri, Apr 10, 2020 at 6:18 PM
= Subject: [dispatch] Heads up - JSON Data Definition Format (JDDF)
To: &= lt;dispatch@ietf.org= >
Cc: <draft-ucarion-json-type-definition@ietf.org&= gt;


Hi Dispatch,

draft-ucarion-json-type-definition has been presented to the Independent Submissions Editor for publication as an RFC.

During review it was suggested to me that the topic might be of sufficient<= br> interest that a WG could be formed, but there doesn't seem to be quite<= br> that level of enthusiasm.

In discussing this with the ADs, they suggested I should flag this to you.<= br> I'd certainly be interested in hearing any comments, and if Dispatch wanted to take this on that would be worth knowing.

Thanks,
Adrian
--
Adrian Farrel (ISE),
rfc-ise@rfc-edi= tor.org

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000e3b44805a32f36d9-- From nobody Mon Apr 13 13:30: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 C125B3A1DAE for ; Mon, 13 Apr 2020 13:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zZ_VSfSg_E78 for ; Mon, 13 Apr 2020 13:30: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 B661E3A1DAD for ; Mon, 13 Apr 2020 13:30:45 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 491Kxv2CrmzyRy; Mon, 13 Apr 2020 22:30:43 +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: Mon, 13 Apr 2020 22:30:42 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 608502642.726771-866c65f7094ccd0598f42b71e1980472 Content-Transfer-Encoding: quoted-printable Message-Id: <41912BFE-5700-4B4E-87EF-46FC65FB1E33@tzi.org> References: <8dc45105cca508bc6981e0be2b709508.squirrel@www.rfc-editor.org> To: Ira McDonald X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] [dispatch] Heads up - JSON Data Definition Format (JDDF) 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, 13 Apr 2020 20:30:49 -0000 On 2020-04-13, at 19:14, Ira McDonald wrote: >=20 > Hi, >=20 > FYI >=20 > This JDDF in the ISE appears to overlap w/ CDDL - is anyone in CBOR WG=20= > watching this one? Hi Ira, I certainly am; we had some discussions over in the JSON WG mailing = list. JDDF is a rather minimal form of a data definition format for JSON data = that is itself represented in JSON (I=E2=80=99ll call that homoiconic = here). I find it interesting as it seems to be quite useful even in its = minimal design. CDDL (RFC 8610) is different from JDDF (and other homoiconic data = definition format proposals) in that it is a language, i.e. it is meant = for human use, e.g., in specifications. It is based on grammar concepts, as is ABNF (RFC 5234), so it has a = wide, orthogonal gamut of expressiveness compared to the sometimes = somewhat cobbled-together homoiconic proposals. It also covers the wider generic data model of CBOR, not just that of = JSON. =20 https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer-03#section-8 = defines a JSON representation of CDDL specifications, which might be = used in a similar way that JDDF and other homoiconic approaches are = being used. I=E2=80=99m proposing to document this form in a = specification so it becomes easier to interchange parsed CDDL between = tools. =20 (An implementation of a parser frontend is at = https://github.com/cabo/cddlc =E2=80=94 this also provides a reencoding = of the JSON format in the popular YAML format, which is a bit more = useful to humans.) Gr=C3=BC=C3=9Fe, Carsten >=20 > Cheers, > - Ira >=20 >=20 > ---------- Forwarded message --------- > From: RFC ISE (Adrian Farrel) > Date: Fri, Apr 10, 2020 at 6:18 PM > Subject: [dispatch] Heads up - JSON Data Definition Format (JDDF) > To: > Cc: >=20 >=20 > Hi Dispatch, >=20 > draft-ucarion-json-type-definition has been presented to the = Independent > Submissions Editor for publication as an RFC. >=20 > During review it was suggested to me that the topic might be of = sufficient > interest that a WG could be formed, but there doesn't seem to be quite > that level of enthusiasm. >=20 > In discussing this with the ADs, they suggested I should flag this to = you. > I'd certainly be interested in hearing any comments, and if Dispatch > wanted to take this on that would be worth knowing. >=20 > Thanks, > Adrian > --=20 > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From mail@joachim-breitner.de Tue Apr 14 02:53:28 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 528DA3A0942 for ; Tue, 14 Apr 2020 02:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=joachim-breitner.de 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 zQMzEgtXGRl3 for ; Tue, 14 Apr 2020 02:53:26 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD8C3A0940 for ; Tue, 14 Apr 2020 02:53:25 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 491gm354RpzKmcN for ; Tue, 14 Apr 2020 11:53:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joachim-breitner.de; s=MBO0001; t=1586857999; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/ArRGVWQ31wi3ALPFzRAIuYWHEOL+f2ykTfTYRm8Gyc=; b=dvKKY7/XRo5NN2Bx0f1cI+9P2y/SdnDC6yQM9hPqzEmtA2MiI2K/12TJ353cs6wlqSpDHl f51z3g931aLy0Ad0pe9/7sLMPS9AwSdhXwrluYe0gGE5L+XaHXXBZoYl1tlqMRACO8ZY0x oaqVPWYR8up+aqZtPB3QbQQcEwf4Wb/zTmooDQF+cVeMFLjv+O2Ec3yzyjygYs5sgEP14v R2riAwo4OD3A3aotFXxu/IHd8g2BGhU8arHHUPTrE9bMMuXiWAsKQ6IWcr2R9rV6tmkShR bwNFXUEbFXqGuxPoqP2Q3gZsDjrf3tt5G+Khwfg3r007I1H5RPQppjKMusW8jg== Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id ffUZQxdCOYT5 for ; Tue, 14 Apr 2020 11:53:18 +0200 (CEST) Message-ID: From: Joachim Breitner To: cbor@ietf.org Date: Tue, 14 Apr 2020 11:53:17 +0200 Content-Type: text/plain; charset="ISO-8859-15" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C49341753 X-Rspamd-Score: -3.88 / 15.00 / 15.00 Archived-At: Subject: [Cbor] CDDL: Multiple root files / file includes 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, 14 Apr 2020 10:01:39 -0000 Dear group, I started playing around with CDDL, but I am facing a minor problem, and would like to hear your advice: I need to define multiple types (e.g. request and responses) that share common definitions. I currently begin my file with ; This "root type" of this CDDL file is a hack: We want to define multiple ; types in one file (to shared common definitions), but CDDL requires a single ; root type. So we just list the types defined here: defined-here = request / response but this is obviously a hack, and while good enough to use CDDL for documentation, it will break certain tool usages. I was expecting either a way to label multiple types as (named) root types, and tools would allow me to select which type I want to generate/validate/etc. Or a way to include other files, similar to the implicitly included prelude, so that I can put common definitions in common.cddl and then have indeed a request.cddl and response.cddl import that file. But maybe there is yet another way? How do you solve this issue? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ From nobody Tue Apr 14 03:53:19 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 2C3C03A0AB7 for ; Tue, 14 Apr 2020 03:53:17 -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 J5QPyy8tEaur for ; Tue, 14 Apr 2020 03:53:13 -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 894AA3A0AB6 for ; Tue, 14 Apr 2020 03:53:13 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 491j533RRlz10HD; Tue, 14 Apr 2020 12:53:11 +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: Tue, 14 Apr 2020 12:53:10 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 608554390.866776-2c5660a959529e4c5c1369314d38213c Content-Transfer-Encoding: quoted-printable Message-Id: <71A3F2C4-FF72-42F3-8ECC-C47C6020BE71@tzi.org> References: To: Joachim Breitner X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL: Multiple root files / file includes 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, 14 Apr 2020 10:53:17 -0000 Hi Joachim, > defined-here =3D > request / > response That is pretty much what all CDDL users do. E.g., see RFC 8152 section 1.3 near the end [1]: start =3D COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types I wouldn=E2=80=99t call it a =E2=80=9Chack=E2=80=9D, but rather an = =E2=80=9Cidiom=E2=80=9D=E2=80=A6 Maybe we=E2=80=99ll add something like an export interface (and, more = importantly, imports) in the next round of updating CDDL. The CDDL = freezer [2] contains some initial thoughts about this; it you could = consider the requirements that you have in this space and post them = here, that would help. For now, the =E2=80=9Cstart=E2=80=9D idiom should work fine. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/rfc8152#section-1.3 [2]: = https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer-03#section-7= From nobody Tue Apr 14 04:02:23 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 F32F63A0AF8 for ; Tue, 14 Apr 2020 04:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=joachim-breitner.de 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 HnHxCe65FirU for ; Tue, 14 Apr 2020 04:02:19 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5DD3A0B4D for ; Tue, 14 Apr 2020 04:02:03 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 491jHD0jPkzKmTp for ; Tue, 14 Apr 2020 13:02:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joachim-breitner.de; s=MBO0001; t=1586862117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Cby44xyruDoBtkHwjwCzMevOE4N2eSrVuz2rBLofoqQ=; b=MirwgzQlv0VvbLPCHBEJtQsAz1E7jVnqCLZu1qnQvQsupsOF/wU4388Kc2QevH7QOEQ1gJ 69TiGStnecf9328/R3iK199+uYYAALPfy5sMl9l/Re1MNoZmLCwKAHTZVRSQX0RkkLdsz5 pJWVBmegcptZuHzpTt0odvCo1FKjAsNuFLblmT4igTyEJJkEHAf07oXS/zSZ8RdaSLSgC2 ZPvKFI6gcK5sDdXxS2oZZH5HNV8zTZEFe4nZfPBXsWfElsxx7sSESbcKEHdP+X02/w3/fw P/v6URUOZIztsWdBQhD25Lid4ikz3yj3f618Xqmy8ck+mz3VvY9+6ZZSBgqcwA== Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id D-kgA2bu6fYf for ; Tue, 14 Apr 2020 13:01:55 +0200 (CEST) Message-ID: <0340c22e2b8c715a329a5a95a284884c4d76a47a.camel@joachim-breitner.de> From: Joachim Breitner To: cbor@ietf.org Date: Tue, 14 Apr 2020 13:01:54 +0200 In-Reply-To: <71A3F2C4-FF72-42F3-8ECC-C47C6020BE71@tzi.org> References: <71A3F2C4-FF72-42F3-8ECC-C47C6020BE71@tzi.org> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C3011173E X-Rspamd-Score: -5.64 / 15.00 / 15.00 Archived-At: Subject: Re: [Cbor] CDDL: Multiple root files / file includes 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, 14 Apr 2020 11:02:21 -0000 Hi, Am Dienstag, den 14.04.2020, 12:53 +0200 schrieb Carsten Bormann: > For now, the “start” idiom should work fine. thanks! Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ From nobody Tue Apr 14 04:16:20 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 25A193A0B46; Tue, 14 Apr 2020 04:16:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158686297761.19118.2929535675004111176@ietfa.amsl.com> Date: Tue, 14 Apr 2020 04:16:17 -0700 Archived-At: Subject: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-22 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, 14 Apr 2020 11:16:19 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Concise Binary Object Representation Maintenance and Extensions (cbor) Working Group will hold a virtual interim meeting on 2020-04-22 from 17:00 to 18:00 Europe/Paris (15:00 to 16:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mf05c47a9a418179e3e810a151dcb25a9 Meeting number (access code): 647 836 420 Meeting password: emHrigC22K4 From nobody Tue Apr 14 15:47: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 E21D53A11D7 for ; Tue, 14 Apr 2020 15:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 h9LgZA8SI_Sw for ; Tue, 14 Apr 2020 15:47:09 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 6DC213A11D5 for ; Tue, 14 Apr 2020 15:47:09 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id i22so1430451otp.12 for ; Tue, 14 Apr 2020 15:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vLvG9jxBPOHpGKIwsC0C3I9lk/KUcaov7+VZTQhH36s=; b=XTXVvTGyFJPF+yv5CB6r2e0Gyq6431jp5WHtiBYovxUgsmGz6pQAy71JgaL+odCTnq kX4xPsGRYJpMm+AzkM/yGkbmU2B5r8tl5HqLXDmBmLtB/FfBnBUgcr7ctPeHpe/qZXES I19y1CYYXf2hwGGh4pgk5VV9vSl82TnpH4QBAi961COzIvEjLiGpI0I+y6hG7/iYU98g qIRIXcgdxEtxyykr/sd9UfjJEDbnIaJ/bnWdyVLDsmeodS1ySNowUO0TMWG9FY8gShNh ukUr4Wh0r4gITZATPdFB4RIoaKRV9u1QWqW2/acy/vomjeaBO4Z93ekyK3JSb97d3o0+ UEGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vLvG9jxBPOHpGKIwsC0C3I9lk/KUcaov7+VZTQhH36s=; b=gPuHB2SkvHEAQaEGoh7zHpF/fHXl4GPdMU0QGuDITChFgo0eH3CAVqOgoc/tqDTR4v QSmv8NFQaG+x8QUjVHdvhsEIJe4qnFsJcPzUR7waoADbDBZC7YgID2i9a6XhyYJDD0GJ T8mFLR/eokEV1e81g8ViMScPOwYAnL/3W+EBl6AMLBznJJgid2nMl8eaVtXy9AUX9eDl ELTVp1FNvBUjsugxigahbZHvfGxk4UbNPwrgcnjh4Pvez59HpKs8wrgw6/78/oa+htke e7Kx1P6qewXw7lqrYe6O3ONGhXDxZKAtlnOKrgc/Z3RiWiop7Znc93f+6wL3ju8FJ3Ke 7wqA== X-Gm-Message-State: AGi0PuZ9NuwUc2EaBVHxToTDKOJTgFgCoydUAeXkjdX8SFSfSxDiZufu bVp+xy0OhtA6oJ1YlQMPuwLM4cTY7aVdDyP16mFPHGg/ X-Google-Smtp-Source: APiQypJrxsSO9tkeHZ4QLfaylmqtrugae1VVeMAg6+wj2it1dncRXKGzzXlNjJz3TXtAVC46BT1rYtITsJTDWiWM9p0= X-Received: by 2002:a9d:6041:: with SMTP id v1mr10303728otj.66.1586904428328; Tue, 14 Apr 2020 15:47:08 -0700 (PDT) MIME-Version: 1.0 From: David Kemp Date: Tue, 14 Apr 2020 18:47:00 -0400 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000be3d0c05a347fa40" Archived-At: Subject: [Cbor] CDDL: Multiple root files / file includes 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, 14 Apr 2020 22:47:11 -0000 --000000000000be3d0c05a347fa40 Content-Type: text/plain; charset="UTF-8" Hi Joachim, We've faced the identical question in OpenC2 - the approaches we've considered (using JSON Schema, not CDDL) are: 1) Create separate schema files for request and response - this seems to be what most tools and developers expect. But the common definitions are duplicated and must be kept in sync. 2) Create a single schema with a root object anyOf(request, response) - that is a hack as you say, because the schema will validate a response when you're expecting a request and vice versa. Forget about that. 3) In the schema define a root map containing request and response, and then wrap incoming data with the appropriate key before validating. That keeps everything in one place, but some people don't like the extra wrapping step. root = { req: Request, rsp: Response } 4) Maintain 3 source files: request, response, and common definitions. Use tooling to process the includes, generating separate request and response schemas as in 1). Our approach is to create a single file containing everything, and then use tooling to generate both separate schemas (1) and a single schema with root map (3) from it, allowing developers to choose which format they prefer. --000000000000be3d0c05a347fa40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joachim,

We've faced the identical question = in OpenC2 - the approaches we've considered (using JSON Schema, not CDD= L) are:

1) Create separate schema files for request and response - t= his seems to be what most tools and developers expect. But the common defin= itions are duplicated and must be kept in sync.
2) Create a single schem= a with a root object anyOf(request, response) - that is a hack as you say, = because the schema will validate a response when you're expecting a req= uest and vice versa.=C2=A0 Forget about that.
3) In the schema define a = root map containing request and response, and then wrap incoming data with = the appropriate key before validating.=C2=A0 That keeps everything in one p= lace, but some people don't like the extra wrapping step.
=C2=A0 =C2= =A0 root =3D {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 req: Request,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 rsp: Response
=C2=A0 =C2=A0 }
4) Maintain 3 source = files: request, response, and common definitions.=C2=A0 Use tooling to proc= ess the includes, generating separate request and response schemas as in 1)= .

Our approach is to create a single file containing everything, and= then use tooling to generate both separate schemas (1) and a single schema= with root map (3) from it, allowing developers to choose which format they= prefer.
--000000000000be3d0c05a347fa40-- From nobody Tue Apr 14 16:02: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 D1CB33A1216 for ; Tue, 14 Apr 2020 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 9bvq2rr5ZwR0 for ; Tue, 14 Apr 2020 16:02:03 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 AC9013A1211 for ; Tue, 14 Apr 2020 16:02:03 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id w12so1453238otm.13 for ; Tue, 14 Apr 2020 16:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XhVxB+jNOTw3r4PNAuKGqMYxijlePt7w0VtV9ncq/3w=; b=kKSrOTrqaB0RkICR8dtyCbjGjPYnhiLI4iCk150yHnYjkpoJt1iRyDEPC7hWKxNvly lrw/7wxz+R+BBShyqPvf7fgumWdgtXafvffZ7TbH2TYIf+/droUOXWy3XLMlueLoQowV pe5M7u6UR2++MXNdDjtOqri066fa73Xq8G/jyCwhKR4fW3zeTZVfyn/IzEBWy/Llnc80 s32VEf1MrUow0S3VrlvMTUZBAZ8gkzFETsQSqT6qffZfetAxhJ4+8U+VolHvl3bG0Aki gmRizMQ3tyKBF1tlmLpxijUBD2mf3N6sLqmJNhufX1rLDXOeEJsPC8GA46+N8Fy0HM6o uFiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XhVxB+jNOTw3r4PNAuKGqMYxijlePt7w0VtV9ncq/3w=; b=SjN2pH3j3BfpML25vYnByCgiQf9NGSb0QgCZQE9p5mnSVFrRMPidlfk49lGiIyVfp5 dfx4j2RiC638KUBAhf7ml6lAkltdFrgR+/3g+zC2sUSIO/8As+aLqbSLIq1ChvphB9Bb KIIr55W1sEmiNbv2hDQoVcy2mv/mdmVBNo3irKkS1VNN0YuVVarxNmEjJK00noys2NXW 35AioSjhTMDq7bFfkbTQsaYw+i/idmbm1GC5n+w0OUDwodt5FSE6Y2AgkYIFOZZFxyJ8 lNLB21zVbeu5LfwvA5VRTTboGvsevBAme54OAqyHw1gOiBA7A1uCLxfJNu5h75UecG7I RFjg== X-Gm-Message-State: AGi0PubfBoIxvIHlCVP9ChFsjmXYvjz7RSpas9KEXDpqCXJDeIqSG6Rs aXIu/d6r6P8dax0hBUrBG2db/LFNDUpn78LqVBoLwstp/Og= X-Google-Smtp-Source: APiQypKxJ+Zfrhy7e1YkjfZXA8fuERpAi9pxz+KSz6P/zthghpBQw5jKiJXyxmrS+r1sVhu4Rz/5uveccCNxXgwSaZM= X-Received: by 2002:a9d:1a3:: with SMTP id e32mr10974376ote.206.1586905317543; Tue, 14 Apr 2020 16:01:57 -0700 (PDT) MIME-Version: 1.0 From: David Kemp Date: Tue, 14 Apr 2020 19:01:50 -0400 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000be9f2405a3482f46" Archived-At: Subject: [Cbor] CDDL: Multiple root files / file includes 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, 14 Apr 2020 23:02:05 -0000 --000000000000be9f2405a3482f46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > start =3D COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types > I wouldn=E2=80=99t call it a =E2=80=9Chack=E2=80=9D, but rather an =E2=80= =9Cidiom=E2=80=9D=E2=80=A6 I'd call it a hack, based on feedback from JSON Schema users who don't like the idea of having a schema for one thing (e.g. a request) that will validate something else (a response). If everyone does it, then it must work for them. But I'd consider it a "feature request" for syntax and tooling that will extract and combine schema bits. Regards, Dave --000000000000be9f2405a3482f46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0=C2=A0 =C2=A0 =C2=A0start =3D COSE_Messages / COSE_Key / COSE_KeySet / Internal_Ty= pes
> I wouldn=E2=80=99t call it a =E2=80=9Chack=E2=80=9D, but rather= an =E2=80=9Cidiom=E2=80=9D=E2=80=A6

I'd call it a hack, based o= n feedback from JSON Schema users who don't like the idea of having a s= chema for one thing (e.g. a request) that will validate something else (a r= esponse).

If everyone does it, then it must work for them.

Bu= t I'd consider it a "feature request" for syntax and tooling = that will extract and combine schema bits.

Regards,
Dave
--000000000000be9f2405a3482f46-- From nobody Tue Apr 14 23:43: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 A66B83A0FB9 for ; Tue, 14 Apr 2020 23:43:57 -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 0GG1WtpMPH4r for ; Tue, 14 Apr 2020 23:43:55 -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 6B08A3A0FB7 for ; Tue, 14 Apr 2020 23:43:55 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 492CVx0TyDzyXj; Wed, 15 Apr 2020 08:43:53 +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, 15 Apr 2020 08:43:52 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 608625832.477664-06bb90d1a74f57f0fc54d38445b35658 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Kemp X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] CDDL: Multiple root files / file includes 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, 15 Apr 2020 06:43:58 -0000 On 2020-04-15, at 00:47, David Kemp wrote: >=20 > 2) Create a single schema with a root object anyOf(request, response) = - that is a hack as you say, because the schema will validate a response = when you're expecting a request and vice versa. Forget about that. Since there already are named types in the data definition (request, = response in your case), parameterizing the tool with both the CDDL file = and a name defined in that file (and not just the default root) would be = a good way to make use of a CDDL 1.0 specification, even before we have = explicit language features for export interfacing. Good point; I=E2=80=99= ll put that into the next version of the CDDL tool. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 16 02:06: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 11BC63A1268 for ; Thu, 16 Apr 2020 02:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=joachim-breitner.de 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 rJigdYLsM-V3 for ; Thu, 16 Apr 2020 02:06:29 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9ABD3A1267 for ; Thu, 16 Apr 2020 02:06:28 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 492tcy0dgdzKmhP for ; Thu, 16 Apr 2020 11:06:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joachim-breitner.de; s=MBO0001; t=1587027977; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rbYlzPUg5eRW3baSObba4QWECLAKsmbmJYqbkjVoq7U=; b=1AZOjmALYYj1ykA4cWeJxMiMCrYUZXi9Vx3h19TpM4JDvVJMXmPuXVKvOKuvdQxZp92/ji HSJkjTR5Ay4w1gMp1lvB99tNMh9Cp3TwcerghxbRvxj77OomTSpHgFrlCDm06ofQa6cXML 7MY/HEUk5s/B6ePdSV0rN6EjT0jg9r1hjuKLvxyJM6UU9HUdTxypD2p1oqhwCgJO/uHeC3 2Yohm7EWAHfcJEoVSjKHzEdchGMBQeq3RdaOM4Fff30VeOtOm7GggmuAuRJwSIJd8wZ+rd 9qMuVX/NYvEGD/bRQSbCMJVee3AGOhbjUQTt2BZR0itrKVGhYQZoHlXfp6ZxVA== Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id KIbbAQ-nW_8n for ; Thu, 16 Apr 2020 11:06:16 +0200 (CEST) Message-ID: <9b05ad9b4ce09f35923c3732dee900cc99be3de6.camel@joachim-breitner.de> From: Joachim Breitner To: cbor@ietf.org Date: Thu, 16 Apr 2020 11:06:14 +0200 Content-Type: text/plain; charset="ISO-8859-15" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 302EF176B X-Rspamd-Score: -5.39 / 15.00 / 15.00 Archived-At: Subject: [Cbor] cddl tool: Support for generics 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, 16 Apr 2020 09:06:31 -0000 Hi, with a CDDL file accepted by https://cddl.anweiss.tech/ I get an error message like this from cddl 0.8.10: *** Look for syntax problems around the %%% markers: ; A request request = envelope%%%<(%%% some-request / another-request )> *** Parse error at 478 upto 480 of 2141 (3487). Does the cddl tool simply not support instantiating generic rules yet, or is the validator at https://cddl.anweiss.tech/ not precise enough? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/ From nobody Thu Apr 16 05:56:27 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 EF42B3A163F for ; Thu, 16 Apr 2020 05:56:24 -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 uG06U1oOwyBx for ; Thu, 16 Apr 2020 05:56:20 -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 87A523A163D for ; Thu, 16 Apr 2020 05:56:20 -0700 (PDT) Received: from [192.168.217.150] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 492zkB4Sfhz108H; Thu, 16 Apr 2020 14:56:18 +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: <9b05ad9b4ce09f35923c3732dee900cc99be3de6.camel@joachim-breitner.de> Date: Thu, 16 Apr 2020 14:56:18 +0200 Cc: cbor@ietf.org X-Mao-Original-Outgoing-Id: 608734578.041195-6d95d0e74a3ac8ec052059599490f972 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9b05ad9b4ce09f35923c3732dee900cc99be3de6.camel@joachim-breitner.de> To: Joachim Breitner X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Cbor] cddl tool: Support for generics 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, 16 Apr 2020 12:56:25 -0000 On 2020-04-16, at 11:06, Joachim Breitner = wrote: >=20 > Hi, >=20 > with a CDDL file accepted by https://cddl.anweiss.tech/ I get an error > message like this from cddl 0.8.10: >=20 > *** Look for syntax problems around the %%% markers: > ; A request=20 > request =3D envelope%%%<(%%% > some-request / > another-request=20 > )> >=20 > *** Parse error at 478 upto 480 of 2141 (3487). Hi Joachim, my fault, I need to set up the repo for the cddl tool, then you could = submit issues there. > Does the cddl tool simply not support instantiating generic rules yet, It sure does. > or is the validator at https://cddl.anweiss.tech/ not precise enough? No, that just has a better (less buggy) parser. request =3D envelope<(some-request/another-request)> envelope =3D x some-request =3D uint another-request =3D text goes through, request =3D envelope<( some-request/another-request)> envelope =3D x some-request =3D uint another-request =3D text does not. Bug in the aching PEG parser in the cddl tool. The v2 tool, = the first parts of which can be tested under the name of cddlc, accepts = both and generates this JSON representation of the test file: ["cddl", ["=3D", ["name", "request"], ["gen", "envelope", ["tcho", ["name", "some-request"], ["name", "another-request"]]]], ["=3D", ["gen", "envelope", "x"], ["name", "x"]], ["=3D", ["name", "some-request"], ["name", "uint"]], ["=3D", ["name", "another-request"], ["name", "text"]]] Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 21 09:07: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 C388C3A0DC8 for ; Tue, 21 Apr 2020 09:07:44 -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=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 jdvZB0T2e67G for ; Tue, 21 Apr 2020 09:07:41 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.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 E55673A0E95 for ; Tue, 21 Apr 2020 09:07:22 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id QvQfjZ4Pn4NFGQvQgjCxdo; Tue, 21 Apr 2020 09:07:22 -0700 X-CMAE-Analysis: v=2.3 cv=EPx4LGRC c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=WMtHHQaCRWcHGEDLbcIA:9 a=QEXdDO2ut3YA:10 a=UcTN6IUWVUINGMuQfjEA:9 a=4RQ5A1VLkLRPNQEQ: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=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 21 Apr 2020 09:07:21 -0700 In-Reply-To: <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com> Cc: "Smith, Ned" , Henk Birkholz , "rats@ietf.org" , Jim Schaad , "cbor@ietf.org" , Ace Wg To: Carsten Bormann References: <00d501d5f26d$c34454d0$49ccfe70$@augustcellars.com> <12861.1583448208@localhost> <51BE3C8D-6AC9-424F-8600-57ADCAF9CEF5@intel.com> <017f01d5f35d$2c422c60$84c68520$@augustcellars.com> <01ae01d5f3eb$4a670fb0$df352f10$@augustcellars.com> <3F7E9A70-18BE-454C-A5EB-F07A1EDFE7DC@island-resort.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfF4SID21nOVc+Hqcj19ynLHV7g/QQGgOBc80lxQWhb31uVS8bzgJSRGrKKs5kEBtve7L9ao0lrmNkaN48tHAnA5q2mNwC1+caCmrbjyHqHFeZiK3ki3y AsrRKKAJLFnqgBOGaz4Q+lYRnF3ZS1x6YAaqpVG12nt8gqEcUZWdL14DFJDzLzjDg/+07PQ9+U+GHtJG7cgWYprmER7jUMINTAjlS38PFS1M5p9pCOqbq3dV hHcqjtdS/d92ofjRftV5b++eMz48n6u+QrrwxO+MxqsKJM2+QAvk1d1ADxIA8R2BjNZvjFkIgP2v34OZGtz202KV96LVfH0jfjtJiUpaPsQ= Archived-At: Subject: Re: [Cbor] [Rats] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? 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, 21 Apr 2020 16:07:45 -0000 --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have created a PR = against the EAT draft for UCCS and UJCS. I=E2=80=99m not sure this = really belongs in the EAT draft, but I thought I=E2=80=99d start by = putting it there. LL P.S. If we were do an update to CWT to accommodate this, it would also = be good to add CDDL describing CWT. That is another thing I=E2=80=99ve = got in the EAT draft, that probably belongs elsewhere. > On Mar 6, 2020, at 6:27 PM, Laurence Lundblade = wrote: >=20 > Pretty sure UCCS as Carsten describes below works for me provided: >=20 > - All the rules and requirements from CWT explicilty apply except = signing/encryption > - It uses the same registry > - There is a tag defined for it > - You get an (untagged) UCCS when you remove all signing and = encryption layers >=20 > LL >=20 >=20 >> On Mar 6, 2020, at 12:04 PM, Carsten Bormann wrote: >>=20 >> Hi Ned, >>=20 >> What I was trying to say is that the Unprotected CWT Claims Set = (UCCS) is not a CWT, but an UCCS. So I wouldn=E2=80=99t call it a token = (which implies some form of protection to me). But it is still a useful = data structure to carry around. >>=20 >>> On 2020-03-06, at 20:59, Smith, Ned wrote: >>>=20 >>> The earlier thread suggested that a naked token could be given to a = parser that was programmed correctly and it would 'just work'. But if = the definition of a CWT/JWT is that it must have bounding signature, = mac, encryption enveloping, then the parser should reject naked tokens = (tagged as such or not).=20 >>=20 >> A CWT decoder would diagnose an UCCS as =E2=80=9Cnot a CWT=E2=80=9D. >> A CWT/UCCS decoder would diagnose it as =E2=80=9CUCCS=E2=80=9D. >>=20 >>> If the naked token is defined and the map has a tag that indicates = it was formed without secure enveloping then the parser should accept = it, but the code using the parser needs to find some other way to ensure = security.=20 >>=20 >> Right. An UCCS is only a useful assertion if received over a secure = channel with the right properties to make it a useful assertion. >>=20 >>> If a parser receives a map with both security enveloping and the = naked token tag, then it should return both the map and the security = envelope context and let the code using the parser decide if the = security context satisfies the security requirement. >>=20 >> Well, it should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not = an UCCS either). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have created a PR against the EAT draft for UCCS and UJCS. =  I=E2=80=99m not sure this really belongs in the EAT draft, but I = thought I=E2=80=99d start by putting it there.

LL

P.S. If we were do an = update to CWT to accommodate this, it would also be good to add CDDL = describing CWT. That is another thing I=E2=80=99ve got in the EAT draft, = that probably belongs elsewhere.



On Mar = 6, 2020, at 6:27 PM, Laurence Lundblade <lgl@island-resort.com> wrote:

Pretty= sure UCCS as Carsten describes below works for me provided:

- All the rules and requirements from CWT = explicilty apply except signing/encryption
- It uses the = same registry
- There is a tag defined for it
- You get an (untagged) UCCS when you remove all signing and = encryption layers

LL


On Mar 6, = 2020, at 12:04 PM, Carsten Bormann <cabo@tzi.org> wrote:

Hi = Ned,

What I was trying to say is that the = Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS.  So I = wouldn=E2=80=99t call it a token (which implies some form of protection = to me).  But it is still a useful data structure to carry = around.

On 2020-03-06, at 20:59, Smith, Ned <ned.smith@intel.com>= wrote:

The earlier thread suggested that a = naked token could be given to a parser that was programmed correctly and = it would 'just work'. But if the definition of a CWT/JWT is that it must = have bounding signature, mac, encryption enveloping, then the parser = should reject naked tokens (tagged as such or not).

A CWT decoder would diagnose an = UCCS as =E2=80=9Cnot a CWT=E2=80=9D.
A CWT/UCCS decoder = would diagnose it as =E2=80=9CUCCS=E2=80=9D.

If the naked token is = defined and the map has a tag that indicates it was formed without = secure enveloping then the parser should accept it, but the code using = the parser needs to find some other way to ensure security.

Right.  An UCCS is only a = useful assertion if received over a secure channel with the right = properties to make it a useful assertion.

If a parser receives a = map with both security enveloping and the naked token tag, then it = should return both the map and the security envelope context and let the = code using the parser decide if the security context satisfies the = security requirement.

Well, it = should diagnose this as =E2=80=9Cnot a CWT=E2=80=9D (and not an UCCS = either).

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

_______________________________________________
RATS mailing list
RATS@ietf.org
https://www.ietf.org/mailman/listinfo/rats

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

= --Apple-Mail=_F9907CDF-6DAB-451F-93E9-2F24DC401FDA-- From nobody Tue Apr 21 18:27: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 0B9013A092F for ; Tue, 21 Apr 2020 18:27:45 -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 v1yZANUvg5zQ for ; Tue, 21 Apr 2020 18:27:43 -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 2D9E83A0919 for ; Tue, 21 Apr 2020 18:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z53Y5aDmZiS86EHRC0kjpjZCCAM7csdf99nepgyjlYdWKxs6azrJUqYWSJLdG/lteGaPh6CzjzA1bsblhMeisJS/JR0Q8aDiPB70jGxLt6uWVm3PCFwy6+ZuVoryau6ebx+S5JIMvgd4sNf4jdxVQ7Y4mRPtlzw+5MSqtAinbzPU8x+XpduyB8LJves2QRbAAvBeJFCWPNXZ18ZEhwOLAijykT7gi8/dM7t0Q3bheDewjx/WISuGycc0w2UV0eTimXl94Oi/pb4KkozlXrT3cmMA1E1HrvaECN4S7E2cYxvX1Bh0VEie3/+DaLLE4aKNwE6+/PB2a68hcHAv9bFLEg== 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=S05eQanXXsxkNA0wqcWAkMa7mDIVh/B6bl2meVuGzlE=; b=kJDjIckwBz8tJcvDxaVgnqZIFjcG2duqRj+Kd8LOwaH15UaTtmn1F41B4fanpbFAfvH7m6ibhYNp+CqP3f7G9hdxn9LNpPUlIgGs62l+4Ae9hE66Y1jExtnWFvnI/SXJdsW9kI/RZ+jxVOGeG0Y3XD678kp4XRsl+viKjL+PqvB2TlIJlIzLUdfavdrBod8HZfOfTptyJLdH2O4HvIjWbDRb/ypKCE7H1m8nQFQKzKivvSYRz5oI4B+J3J0/FDc0Wv1G5qglCWtMzZ15WU0bYP1FIqiL2EGt0i7Dg2NOdpbuaU5VmeObavdA4wucpQzIQWIQDhxrQlZqgdBuVVgwPg== 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=S05eQanXXsxkNA0wqcWAkMa7mDIVh/B6bl2meVuGzlE=; b=H1PtEmsjGC6qASCtqO+lKsMzX5WQtxd9vtAHeMAkd0IEmi/x2dViqsRlD9pj+WKtyRWPaeylhhZ29nm7I+RiAIGf7W914GyoXy9LEIT8vuA5SWZuRhvPKjlwoPQFhCtvR9QnmocrzLlMaq3kZ7rIGTXYCMIUTpZ3kuskFTbgZRk= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0655.namprd00.prod.outlook.com (2603:10b6:208:c8::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2973.0; Wed, 22 Apr 2020 01:27:40 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::7d9c:82d9:f463:13d9]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::7d9c:82d9:f463:13d9%6]) with mapi id 15.20.2973.000; Wed, 22 Apr 2020 01:27:40 +0000 From: Mike Jones To: Carsten Bormann , =?iso-8859-1?Q?Richter=2C_J=F6rg?= CC: "cbor@ietf.org" , Anthony Nadalin Thread-Topic: [Cbor] CBOR tag for RFC 3339 full-date values Thread-Index: AdX7xA8PIgFZYmMBTM6TZdKF95Ac5QABbHMABx7LxhA= Date: Wed, 22 Apr 2020 01:27:40 +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=415cd994-b83f-4773-ab36-00003ebed2be; 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-04-22T01:25:42Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@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: 197dc0db-00ac-4193-5b68-08d7e65c5969 x-ms-traffictypediagnostic: MN2PR00MB0655: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03818C953D received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oRKG3AJ8nftx+WObFEbl15sWU3085IBkPV6C9xNhtQ+yxXv5wj4cK+ag1vCOdcrfQfEbHCY0ziCXMYfjgUWxFQmONhlQyWSsuIXqFROpjGkJRCEYvOWrZHtMaDkdCdSXmhNh6W2miVeMH9qu2r09c1nGVMQDhbui3Y/+OYC4svDMPFMmcFaWtbb8VCRWBmwiCE9c05f0VZrBk7uxhxbH7L/qACQByqiCC8ECQtMN2Qzq3bmeJXM4pQLykj3+ElATs9wOJJ3ehU6qQHzrBnBr5CYgkSlVXGot4q8QV+lULMl2BoY/VjYnVYUv8Qt4QSMJg3X1LRrU4z+Gi28rKFg5idVr7G+PzRqzxTIBX5bMizM8FVUAlzACQAhVY8u7QFtHA7lbdTje9agTDeBAH9Cs2pgNiXQmPA0gt2JoUv9EhqPOkR7XNQ3bWsFHHw3RA0YPbiCEE9jRr1GMRl766/NUFgWOLfWgBsk+g5tEQXx4XIMQ9TrI3CzdbnGy6d5rzxSsNLmRO49dvH5to4r3mGXKVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(107886003)(86362001)(82950400001)(33656002)(52536014)(4326008)(55016002)(82960400001)(9686003)(186003)(64756008)(66446008)(66946007)(66556008)(66476007)(26005)(76116006)(8990500004)(966005)(54906003)(10290500003)(498600001)(110136005)(5660300002)(8936002)(8676002)(66574012)(71200400001)(53546011)(2906002)(7696005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: lYuO3i3fZKzurDPxC7+G9JXKO3UHjssms3LrXqQkdGxDMoQH6qULD7z0Sxq6mKrwCuoueQTPosMlEeZfYzdltH16zfYSd6Wjyl/zVY0lfjDPM+6WrI1pI6V+nu0/5Y9SR9AV/ANzlZ4x5y3FrzoIFdepnEpwlVSAge7jMcxAX7Wq2wYOsx7PlXotcEAdqSObEvGFCd9vz74JUQ0r24M8gpI0h2gfSeDX3tJnaBtWlzr+w7CpXP4FzREXC6zbNcOb8qnHm2OfGHEVGtYriIZKcMUnfX5GdxoTYq5pca6IlxnMJ91ll/6frz0MvGXl4CEi8rgXw8lshrvx3Beq088NOeSPeJkSyb0ApfCWkHpXtogtMJXXcdtQT2tuDmU5XsTMqIuYEvCuzaO4ynyufaC3/duK/+2OzfXq0qeVv0YbOtgros3H4Jc0R16X5TRUxuA1nlUuMlghFccesebM3ljHAi+E1Jp4u9Lzhmil5Br8rk5R6wAbWrYCFmE7MM3AVikA+v+vZ2uFvhsM+mytCAclBpKr7Inm35ItrqKvfI+Pu1UPY9F+r7IMh/M4PAPiT6Z9PwDKqwxsnNxUrmK+Aw4QSVTcullDOZ9GEPFX89QxKFPyO0S/WeaM6zpQ4ilSU1XZttFYl6cwnF/xLJJVsBCztnT4DzYWlHGl6oA9Ww9V+MM4eDB3TJraiMBELsShM0FrxrXbIl6CYcs5CeoyTS6L6WcSXHonhTmkxZ/j2Qzk25uechOfZV0SkgCV4is3UkHdSrlUfa6b74gRMEM16AKxt1b+IJOi3JCXtV8wf11LdnM= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 197dc0db-00ac-4193-5b68-08d7e65c5969 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 01:27:40.5460 (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: M5q/OHaItds/2Wf5l9dNWzPYp+ryJHciCab0MsVE6p+jlbDl8W6kGf5ysn2Z0dX5YaPq2oCwYG7oPJnfsrVRug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0655 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, 22 Apr 2020 01:27:45 -0000 I've posted https://tools.ietf.org/html/draft-jones-cbor-date-tag-01, which= includes the numeric date tag proposed by J=F6rg. I'll plan to join the C= BOR call tomorrow and would be glad to talk about this draft for a few minu= tes, if there's room to do so in the agenda. Best wishes, -- Mike -----Original Message----- From: CBOR On Behalf Of Richter, J=F6rg Sent: Monday, March 16, 2020 12:33 PM To: Mike Jones Cc: cbor@ietf.org; Carsten Bormann ; Anthony Nadalin Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values > J=F6rg - I'll also add you as a co-author. What affiliation and e-mail a= ddress for you should I use? And is there a URL for a blog or Webpage you'= d also like me to include for you? Sorry, I missed this one. You can use joerg.richter@pdv-fs.de (pdv Financial Software GmbH). I got no= blog or webpage. Thanks, - J=F6rg ________________________________________ Von: Mike Jones Gesendet: Montag, 16. M=E4rz 2020 19:52:38 An: Richter, J=F6rg Cc: cbor@ietf.org; Carsten Bormann; Anthony Nadalin Betreff: Re: [Cbor] CBOR tag for RFC 3339 full-date values J=F6rg - please respond to my request below for co-author information. Thanks, -- Mike -----Original Message----- From: Mike Jones Sent: Wednesday, March 11, 2020 3:11 PM To: Carsten Bormann ; "Richter, J=F6rg" Cc: cbor@ietf.org; Mike Jones ; Anthony Nadali= n Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values The point of having the tag is that the code knows what follows. If a poly= morphic tag were used, in which two unrelated representations of dates are = legal, then the code doesn't know what follows. And it also opens up quest= ions that it would be cleaner to never have to consider - questions such as= "If the polymorphic tag is adopted, must Mobile Driver's Licenses accept b= oth representations?" And "Will interoperability be harmed if some Mobile = Driver's Licenses use one representation and some use the other?" (The ans= wer to that one is probably "Yes, interoperability will be harmed".) Carsten, I take your point about both integers and floats being acceptable = for tag 1. But those are closely related (numeric) representations of the = same thing. Whereas a date string versus number of days relative to the Ep= och are nearly unrelated representations, with fairly complicated conversio= n rules between them (involving leap years, leap centuries, leap 400th year= s, etc.). Given that J=F6rg stated below that he's OK with using different tags, I pr= opose that we move forward with using tag 1004 (requested) for RFC 3339 ful= l-date values and tag char('d') (requested) for integer number of days rela= tive to the Epoch. If I don't hear objections soon, I'll publish that draf= t. J=F6rg - I'll also add you as a co-author. What affiliation and e-mail add= ress for you should I use? And is there a URL for a blog or Webpage you'd = also like me to include for you? Cheers, -- Mike -----Original Message----- From: CBOR On Behalf Of Carsten Bormann Sent: Wednesday, March 11, 2020 2:09 PM To: "Richter, J=F6rg" Cc: cbor@ietf.org; Mike Jones ; Anthony Nadalin Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values On 2020-03-11, at 21:31, Richter, J=F6rg wrote: > > (Replying to more than one message here) > > Carsten Bormann: >> Is that a good way forward? > > I am fine with the suggested procedure. Great! > >> What I like about Mike's draft is that he references RFC 3339, which=20 >> already is an established specification for how to write dates=20 >> textually > > ISO 8601 also defines this format for dates. It is mentioned in the "Deta= iled Semantics" > section of my proposal. ISO 8601 is very "flexible". RFC 3339 uses ISO 8601, but helps by restrict= ing this to commonly used cases. So I think referencing RFC 3339 is strictly better than just naked ISO 8601= . > Mike Jones: >> I'm fine merging J=F6rg's numeric date tag into my draft, provided that= =20 >> the result is not a polymorphic tag, in which the value could be either = a number or a string. >> We should allocate separate tags for string date and numeric date,=20 >> just as tags >> 0 and 1 are different, and not polymorphic. > > I've got the impression that using a polymorphic tag would be no major pr= oblem. > We can even specify that decoders might only support one representation o= f the tag. > I think it would have the same effect if a decoder supports only one of t= he two tags. > But either way I would have no objections to using two tags. I'm not sure I like the term "polymorphic" here too much - in any case, the= "value" would be a date. The content could be both text and number. Tag = 1 already does this (integer vs. floating-point), so we already have to dea= l with these (i.e., allow applications to not just say "Tag 1", but "Tag 1 = with integer content"). But we did separate Tag 0 and Tag 1, mostly becaus= e the semantics of the value are subtly different. Are they here? > Laurence Lundblade: >> I'd suggest the numeric date be restricted to integers. No floats,=20 >> bignums, decimal fractions. > > Yes, that was the plan. Only major types 0 and 1. Finer granularity between dates would be times, which we already have, so t= his naturally should be integers. >> Fractions of days can be represented by tag 0 or tag 1 using hours,=20 >> minutes, seconds. 64-bit integer counts of days are large enough. > > This I don't understand. The proposal only handles whole days as one numb= er. Right. Only full days. (The related observation is that these are always = in the local time of some context that is not expressed, which is rather di= fferent from our time tags.) > Another thing to consider: > We should mention that this tag(s) use the proleptic Gregorian=20 > calendar. So that dates before the Gregorian calendar have a unique seman= tics. Good point. In 7049bis, we just say: Negative values (major type 1 and negative floating-point numbers) are inte= rpreted as determined by the application requirements as there is no univer= sal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this i= s particularly true for points in time that precede discontinuities in nati= onal calendars). [.] That is less of a problem on the date-only side (as long as dates change on= local midnight. and not noon), so we may be able to be more specific. Gr=FC=DFe, 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 From nobody Tue Apr 21 21:15:26 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 5878A3A0D42 for ; Tue, 21 Apr 2020 21:15:23 -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 bk5clJiyp91k for ; Tue, 21 Apr 2020 21:15:20 -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 1A69E3A0D40 for ; Tue, 21 Apr 2020 21:15:19 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 496RtC5CFXzytv; Wed, 22 Apr 2020 06:15: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, 22 Apr 2020 06:15:15 +0200 Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 609221715.2957031-ef7ba02909a002b6163d18b8de02adba Content-Transfer-Encoding: quoted-printable Message-Id: <177843BB-BEA1-4C26-A85F-7C2C9F330517@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, 22 Apr 2020 04:15:23 -0000 Hi Mike, thanks for submitting the draft! I=E2=80=99d include the value zero (i.e., 1970-01-01 itself), not just = positive or negative values. (Throughout the CBOR related work, we have avoided =E2=80=9Cpositive=E2=80= =9D and usually said =E2=80=9Cunsigned=E2=80=9D, which includes zero.) s/applicaitons/applications/ Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-22, at 03:27, Mike Jones = wrote: >=20 > I've posted https://tools.ietf.org/html/draft-jones-cbor-date-tag-01, = which includes the numeric date tag proposed by J=C3=B6rg. I'll plan to = join the CBOR call tomorrow and would be glad to talk about this draft = for a few minutes, if there's room to do so in the agenda. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Richter, J=C3=B6rg > Sent: Monday, March 16, 2020 12:33 PM > To: Mike Jones > Cc: cbor@ietf.org; Carsten Bormann ; Anthony Nadalin = > Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 >> J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >=20 > Sorry, I missed this one. >=20 > You can use joerg.richter@pdv-fs.de (pdv Financial Software GmbH). I = got no blog or webpage. >=20 > Thanks, >=20 > - J=C3=B6rg >=20 > ________________________________________ > Von: Mike Jones > Gesendet: Montag, 16. M=C3=A4rz 2020 19:52:38 > An: Richter, J=C3=B6rg > Cc: cbor@ietf.org; Carsten Bormann; Anthony Nadalin > Betreff: Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > J=C3=B6rg - please respond to my request below for co-author = information. >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Mike Jones > Sent: Wednesday, March 11, 2020 3:11 PM > To: Carsten Bormann ; "Richter, J=C3=B6rg" = > Cc: cbor@ietf.org; Mike Jones ; Anthony = Nadalin > Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > The point of having the tag is that the code knows what follows. If a = polymorphic tag were used, in which two unrelated representations of = dates are legal, then the code doesn't know what follows. And it also = opens up questions that it would be cleaner to never have to consider - = questions such as "If the polymorphic tag is adopted, must Mobile = Driver's Licenses accept both representations?" And "Will = interoperability be harmed if some Mobile Driver's Licenses use one = representation and some use the other?" (The answer to that one is = probably "Yes, interoperability will be harmed".) >=20 > Carsten, I take your point about both integers and floats being = acceptable for tag 1. But those are closely related (numeric) = representations of the same thing. Whereas a date string versus number = of days relative to the Epoch are nearly unrelated representations, with = fairly complicated conversion rules between them (involving leap years, = leap centuries, leap 400th years, etc.). >=20 > Given that J=C3=B6rg stated below that he's OK with using different = tags, I propose that we move forward with using tag 1004 (requested) for = RFC 3339 full-date values and tag char('d') (requested) for integer = number of days relative to the Epoch. If I don't hear objections soon, = I'll publish that draft. >=20 > J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Wednesday, March 11, 2020 2:09 PM > To: "Richter, J=C3=B6rg" > Cc: cbor@ietf.org; Mike Jones = ; Anthony Nadalin = > Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >=20 > On 2020-03-11, at 21:31, Richter, J=C3=B6rg = wrote: >>=20 >> (Replying to more than one message here) >>=20 >> Carsten Bormann: >>> Is that a good way forward? >>=20 >> I am fine with the suggested procedure. >=20 > Great! >=20 >>=20 >>> What I like about Mike's draft is that he references RFC 3339, which=20= >>> already is an established specification for how to write dates=20 >>> textually >>=20 >> ISO 8601 also defines this format for dates. It is mentioned in the = "Detailed Semantics" >> section of my proposal. >=20 > ISO 8601 is very "flexible". RFC 3339 uses ISO 8601, but helps by = restricting this to commonly used cases. > So I think referencing RFC 3339 is strictly better than just naked ISO = 8601. >=20 >> Mike Jones: >>> I'm fine merging J=C3=B6rg's numeric date tag into my draft, = provided that=20 >>> the result is not a polymorphic tag, in which the value could be = either a number or a string. >>> We should allocate separate tags for string date and numeric date,=20= >>> just as tags >>> 0 and 1 are different, and not polymorphic. >>=20 >> I've got the impression that using a polymorphic tag would be no = major problem. >> We can even specify that decoders might only support one = representation of the tag. >> I think it would have the same effect if a decoder supports only one = of the two tags. >> But either way I would have no objections to using two tags. >=20 > I'm not sure I like the term "polymorphic" here too much - in any = case, the "value" would be a date. The content could be both text and = number. Tag 1 already does this (integer vs. floating-point), so we = already have to deal with these (i.e., allow applications to not just = say "Tag 1", but "Tag 1 with integer content"). But we did separate Tag = 0 and Tag 1, mostly because the semantics of the value are subtly = different. Are they here? >=20 >> Laurence Lundblade: >>> I'd suggest the numeric date be restricted to integers. No floats,=20= >>> bignums, decimal fractions. >>=20 >> Yes, that was the plan. Only major types 0 and 1. >=20 > Finer granularity between dates would be times, which we already have, = so this naturally should be integers. >=20 >>> Fractions of days can be represented by tag 0 or tag 1 using hours,=20= >>> minutes, seconds. 64-bit integer counts of days are large enough. >>=20 >> This I don't understand. The proposal only handles whole days as one = number. >=20 > Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) >=20 >> Another thing to consider: >> We should mention that this tag(s) use the proleptic Gregorian=20 >> calendar. So that dates before the Gregorian calendar have a unique = semantics. >=20 > Good point. In 7049bis, we just say: >=20 > Negative values (major type 1 and negative floating-point numbers) are = interpreted as determined by the application requirements as there is no = universal standard for UTC count-of-seconds time before = 1970-01-01T00:00Z (this is particularly true for points in time that = precede discontinuities in national calendars). [.] >=20 > That is less of a problem on the date-only side (as long as dates = change on local midnight. and not noon), so we may be able to be more = specific. >=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 Wed Apr 22 01:48: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 DBEC53A0B9F; Wed, 22 Apr 2020 01:48:00 -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=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 zfmqELsovMQX; Wed, 22 Apr 2020 01:47:59 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40040.outbound.protection.outlook.com [40.107.4.40]) (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 DC67A3A0B9C; Wed, 22 Apr 2020 01:47:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SnXEcS0yBvP4CwPGfBUNHXAQIrT5IalsEEqePljV5t00e0kDizAp9yUXV/RDiSSPlCVza+EqSdo6SSxjq949D3NhjPPjeJi9ipoFOcoeY3XaC9adEAxh1w5/dY5NkPF1P9j7BlzX3xYU6X+PO3mb0UOXLm5o/v0HMrsUODkjUR3JAvjEG2e9OZg7CdY6/QXILdKqfg/vRD4NvFNdpxg5JfM8NFT266FVI60nUK24OvvXP09wuinfqttIN51iHO5s2kxE+TgaCgEzRwCvUlmLAwK6R2ZZojj8FR93BKp5veiarJktINqfbuhvfRkteQOSRRIg1Huz/juOHpOOf3PuMA== 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=+GSa9i+MRQal/la0GQO0ge7vhO5hEGy+AHabqEt50h0=; b=X99HZh4q0aGbBOHxtWDlw2o2AVQ3gq73B1hUj4Xeu6c0twox7vbMwzPbREfju7A8HxnGBNSSa6EoV/1po9gbAmXoTmEpiZ+ucl5Oc8JVisNx16fGp/EuMGwBUvtwsO9rIkyXYKCK4c/Ai4joDLUoUUMOug+/3ufkpATUZpU6TD9YPUXEEiaUEyaxlc+jOsyxMF4/+VcHiMu1BYMLW41ARW/mi7IrjwzAZzRb/VmsmIoUL1JShQjB3DsGqK72lbsej0nPREOLJj+cMI1xVXX16kvDvvwgepGpi6NbWgzRcPZCH+bPddiDrtBAYXC1wgC0eAmO/GJwyklwoFa5PE3Anw== 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=+GSa9i+MRQal/la0GQO0ge7vhO5hEGy+AHabqEt50h0=; b=lvZEnadps5YLxjdvhv/P8s/Z0HetEz8OCUIRIq8d6JEuG9DY+drmYDnaSoXfiysCUm9v0TOrzKe2NRk9fJDV25cvpF2/M48QVYwO22AnrKSFPgDusbtju1YOEUWIoH8HNgba/O8HGi2tBViyy0HKZvpj4GftwGIvWtkRdkXnhO4= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3660.eurprd07.prod.outlook.com (2603:10a6:7:8d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.9; Wed, 22 Apr 2020 08:47:56 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 08:47:56 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-22 Thread-Index: AQHV9+QXzjsNlGMKaUuh5IIFAy2n/aiFNyqA Date: Wed, 22 Apr 2020 08:47:56 +0000 Message-ID: <41E5693B-BA6E-4149-B074-63B909394FC1@ericsson.com> References: <158395835874.1724.4992235217550293729@ietfa.amsl.com> In-Reply-To: <158395835874.1724.4992235217550293729@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7df9a05-dc2e-4c65-4811-08d7e699da4e x-ms-traffictypediagnostic: HE1PR0702MB3660: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03818C953D 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)(346002)(376002)(39860400002)(366004)(136003)(396003)(76116006)(33656002)(66476007)(66556008)(478600001)(16799955002)(66446008)(64756008)(6486002)(66946007)(6512007)(5660300002)(86362001)(4326008)(186003)(450100002)(36756003)(2906002)(2616005)(8936002)(6916009)(316002)(26005)(66574012)(71200400001)(8676002)(81156014)(966005)(6506007)(44832011); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NaPwzXWGOnHGDNKjJ0hoMcSdVWCbND3Ahybe6vbL+UVssvFOPWbrgrTWJ/svASGUhCGsyAu4xLBFpA5PMIijpfjqGe7MajosZ6StyMORjGVL0P3OVF/MwQAiPoUpX/hioG308gPoIinCdnp2Lu8w7EDAqCzsW4Wqqpm9SmBYxwrTJbQqfXwrCjbMN6s4EANQ56yv4nK92Bb3O+ZpFccTHy9UpExz5e7kZMRKoOH7rvSsnb1DOWEFb4sBEfnytLxjKrVgCbgsNSPwwzrnkUhJupCs6bMKis+jbgT1b6g+FhLcBhEWGM6CFTOzWkfv70t4g7iJIiC2jVn1bk/ouui2EDqMy7zif2opi01GKsYTL0ngy6wMQqqfz+17nHGTxJa5dZLGgZmSitlmsXTKSDSlJSFMdbiGCMyTq36ySeFcTaDEouqqfBI+/nYCSXVBuGn6PEXr6kvLA/fdJlQ4+XrOUx5mxdjzTEZ/EkTCDE9ILXJxhILnx2aPuBsvH+cEEnZAFZElVTFy5R1NDPe6PU9T7w== x-ms-exchange-antispam-messagedata: WdJbyvNZAkDog4qOWqyTCiL4dh2HqPvzXTeHDtESwCCoAQ9vXlYdek7zdYRJSVRCI8tkiWZZeJODBwLAwLq1aUc+pPIMiyj1SxTdiKc6tU3qnGWBd184A040fwnZPCA7V1aaz7bK2A6G5do3ATkhn8WCNn9aJx+WtyMS4G7fbW/x7KCOx1VKbJJD5JKfFTcwrl+6iYWaDcdVv9CwKCxVMD5/jypnUiJN/c1nXUWbqlbuQnsQ2JZvYajmIuM16xxFzKIOf/HuBykXuE3cAXXMzBVW4+GWVJU/eMgptXiNc2M0nu6vzZdc/Zyc+MqZm5K0o4FdB+hqtyLYsObTjQYIRPFHuC9BxJBmV/1uw91eL7qSLvSotChZOFiDPnmBgUqk/uOwmdcn/VAuKTjOBSaUovEAZQDmjsylp2/a27vnuhnLApHBGWUxXFI09bcNByaw1vLFffo6n1JF/0fcTLk/3R/UzumcHkpplPT6dF+43V6UzfuC4qEZ8QQkVdvtiMUW/6n0yuLu7ZPyOMYvjKi6ZsxkIV8M3BNoNbTaSDHDPqOWSKxdlxFAnwfnfONLaqx+aeXxn9Me+FrZu5GmQUB+Wz3yKF4EXvJN8CF4Ox4xZvzOuN8AKXCDAJqAs/oT2oKzZZKRuAO81Hx8UgqQlFImzLux7ORwdkYf6/tlvldwm3sYXxZae2zkwdZw/wCvRQ/UYqhWeKpzS5LV5aQWQDk+hgrRinLQjv39w0Ced1oRnep6yyKSYp8CbSLg4uT7yHEWdW2uMHZoL8UPtFHcKOyF2pwHwQCxMFzST0Dy1fSuK8zkzz5cykqokCuh5pOlqqE1 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <870FB4C924FC204383381798680B670F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7df9a05-dc2e-4c65-4811-08d7e699da4e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 08:47:56.2513 (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: n93xLsEIfMcZUsyW7Xd6z77z2LsnggI/oxBJ2KKNc/iQinJiIWu7XyJIuRVexEECuA5/Vx4P7G3MRgNRXJOAO+qf1aMCe9n150uCRZ3fAAOj/V2dtC8s2yaq5UJdHGAF X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3660 Archived-At: Subject: Re: [Cbor] Concise Binary Object Representation Maintenance and Extensions (cbor) WG Virtual Meeting: 2020-04-22 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, 22 Apr 2020 08:48:01 -0000 SGksDQoNClJlbWluZGVyIHRoYXQgd2UgYXJlIGhhdmluZyBhbiBpbnRlcmltIGxhdGVyIHRvZGF5 LiBUaGUgZHJhZnQgYWdlbmRhIGhhcyBiZWVuIHBvc3RlZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMC1jYm9yLTA3L21hdGVyaWFscy9hZ2VuZGEtaW50 ZXJpbS0yMDIwLWNib3ItMDctc2Vzc2ENCg0KV2ViZXggZGV0YWlsczoNCldlYmV4OiBodHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjA1YzQ3YTlhNDE4MTc5ZTNlODEwYTE1 MWRjYjI1YTkgDQpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDcgODM2IDQyMCANCk1l ZXRpbmcgcGFzc3dvcmQ6IGVtSHJpZ0MyMks0DQoNCkFsc28sIG1pbnV0ZXMgZnJvbSBsYXN0IG1l ZXRpbmcgaGF2ZSBiZWVuIHVwbG9hZGVkLCBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZl IGFueSBjb21tZW50czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVy aW0tMjAyMC1jYm9yLTA2L21hdGVyaWFscy9taW51dGVzLWludGVyaW0tMjAyMC1jYm9yLTA2LTIw MjAwNDA4MTcwMC50eHQgDQpBbmQgcmVjb3JkaW5nczogaHR0cHM6Ly93d3cueW91dHViZS5jb20v d2F0Y2g/dj1BWk5WdzkxZ1pwMCZmZWF0dXJlPXlvdXR1LmJlIA0KDQpUaGFua3MsDQpGcmFuY2Vz Y2ENCg0K77u/T24gMTEvMDMvMjAyMCwgMjE6MzEsICJDQk9SIG9uIGJlaGFsZiBvZiBJRVNHIFNl Y3JldGFyeSIgPGNib3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWVzZy1zZWNyZXRh cnlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgVGhlIENvbmNpc2UgQmluYXJ5IE9iamVjdCBSZXBy ZXNlbnRhdGlvbiBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoY2JvcikgV29ya2luZyBHcm91 cCB3aWxsIGhvbGQNCiAgICBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDIwMjAtMDQtMjIg ZnJvbSAxNzowMCB0byAxODowMCBFdXJvcGUvUGFyaXMuDQoNCiAgICBBZ2VuZGE6DQogICAgKE5v IGFnZW5kYSBzdWJtaXR0ZWQpDQoNCiAgICBJbmZvcm1hdGlvbiBhYm91dCByZW1vdGUgcGFydGlj aXBhdGlvbjoNCiAgICBXZWJFeCBkZXRhaWxzIHdpbGwgYmUgc2VudCB0byB0aGUgQ0JPUiBtYWls aW5nIGxpc3QgYmVmb3JlIGVhY2ggY2FsbC4NCg0KICAgIFRoZSBDQk9SIHdvcmtpbmcgZ3JvdXAg d2lsbCBoYXZlIGNvbmZlcmVuY2UgY2FsbHMgcnVubmluZyBldmVyeSB0d28NCiAgICB3ZWVrcyB0 aHJvdWdoIHRoZSBlbmQgb2YgSnVseSAyMDIwICh1bnRpbCBJRVRGIDEwOCkuDQoNCiAgICBEYXk6 IGV2ZXJ5IG90aGVyIFdlZG5lc2RheSBiZWdpbm5pbmcgb24gOCBBcHJpbA0KICAgIERhdGVzOiA4 LCAyMiBBcHI7IDYsIDIwIE1heTsgMywgMTcgSnVuOyAxLCAxNSBKdWwNCiAgICBUaW1lOiAxNzow MCB0byAxODowMCBDRVQvQ0VTVA0KDQogICAgV2Ugd2lsbCB1c2UgdGhlIHdvcmtpbmcgZ3JvdXAg V2ViRXggZm9yIHRoZSBjYWxscy4gVGhlIElFVEYgV2ViRXgNCiAgICBhY2NvdW50IGRvZXMgbm90 IGFsbG93IEludGVybmF0aW9uYWwgZGlhbGluZyBub3IgVVMgdG9sbCBmcmVlICgiODAwIg0KICAg IG51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhlIFdlYkV4IGFwcCB0byBjb25uZWN0IHlvdXIg ZGV2aWNlIGF1ZGlvLA0KICAgIGFuZCB0aGVyZSdzIGFsc28gdGhlIG9wdGlvbiBvZiBjb25uZWN0 aW9uIGRpcmVjdGx5IGZyb20geW91ciBicm93c2VyDQogICAgaWYgeW91ciBicm93c2VyIHN1cHBv cnRzIGl0Lg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICBDQk9SIG1haWxpbmcgbGlzdA0KICAgIENCT1JAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0K From nobody Wed Apr 22 07:24:52 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 4E6A63A16B2 for ; Wed, 22 Apr 2020 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H2h5WOraZuwO for ; Wed, 22 Apr 2020 07:24:39 -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 7200B3A136A for ; Wed, 22 Apr 2020 07:22:14 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 496jLX4Ggvz108C; Wed, 22 Apr 2020 16:22:12 +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: <177843BB-BEA1-4C26-A85F-7C2C9F330517@tzi.org> Date: Wed, 22 Apr 2020 16:22:12 +0200 Cc: =?utf-8?B?IlJpY2h0ZXIsIErDtnJnIg==?= , "cbor@ietf.org" , Anthony Nadalin X-Mao-Original-Outgoing-Id: 609258132.175396-820129cd4c8df359d0c9e41ccab21702 Content-Transfer-Encoding: quoted-printable Message-Id: References: <177843BB-BEA1-4C26-A85F-7C2C9F330517@tzi.org> 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, 22 Apr 2020 14:24:50 -0000 One other nugget of information that might be useful to minimize = confusion is that the tag-100 date number for a date referenced to UTC, = TAI, TT or similar, is the MJD (Modified Julian Date) number of the day = to the same reference minus 40587. Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-22, at 06:15, Carsten Bormann wrote: >=20 > Hi Mike, >=20 > thanks for submitting the draft! > I=E2=80=99d include the value zero (i.e., 1970-01-01 itself), not just = positive or negative values. > (Throughout the CBOR related work, we have avoided =E2=80=9Cpositive=E2=80= =9D and usually said =E2=80=9Cunsigned=E2=80=9D, which includes zero.) >=20 > s/applicaitons/applications/ >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On 2020-04-22, at 03:27, Mike Jones = wrote: >>=20 >> I've posted https://tools.ietf.org/html/draft-jones-cbor-date-tag-01, = which includes the numeric date tag proposed by J=C3=B6rg. I'll plan to = join the CBOR call tomorrow and would be glad to talk about this draft = for a few minutes, if there's room to do so in the agenda. >>=20 >> Best wishes, >> -- Mike >>=20 >> -----Original Message----- >> From: CBOR On Behalf Of Richter, J=C3=B6rg >> Sent: Monday, March 16, 2020 12:33 PM >> To: Mike Jones >> Cc: cbor@ietf.org; Carsten Bormann ; Anthony Nadalin = >> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >>=20 >>> J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >>=20 >> Sorry, I missed this one. >>=20 >> You can use joerg.richter@pdv-fs.de (pdv Financial Software GmbH). I = got no blog or webpage. >>=20 >> Thanks, >>=20 >> - J=C3=B6rg >>=20 >> ________________________________________ >> Von: Mike Jones >> Gesendet: Montag, 16. M=C3=A4rz 2020 19:52:38 >> An: Richter, J=C3=B6rg >> Cc: cbor@ietf.org; Carsten Bormann; Anthony Nadalin >> Betreff: Re: [Cbor] CBOR tag for RFC 3339 full-date values >>=20 >> J=C3=B6rg - please respond to my request below for co-author = information. >>=20 >> Thanks, >> -- Mike >>=20 >> -----Original Message----- >> From: Mike Jones >> Sent: Wednesday, March 11, 2020 3:11 PM >> To: Carsten Bormann ; "Richter, J=C3=B6rg" = >> Cc: cbor@ietf.org; Mike Jones ; Anthony = Nadalin >> Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values >>=20 >> The point of having the tag is that the code knows what follows. If = a polymorphic tag were used, in which two unrelated representations of = dates are legal, then the code doesn't know what follows. And it also = opens up questions that it would be cleaner to never have to consider - = questions such as "If the polymorphic tag is adopted, must Mobile = Driver's Licenses accept both representations?" And "Will = interoperability be harmed if some Mobile Driver's Licenses use one = representation and some use the other?" (The answer to that one is = probably "Yes, interoperability will be harmed".) >>=20 >> Carsten, I take your point about both integers and floats being = acceptable for tag 1. But those are closely related (numeric) = representations of the same thing. Whereas a date string versus number = of days relative to the Epoch are nearly unrelated representations, with = fairly complicated conversion rules between them (involving leap years, = leap centuries, leap 400th years, etc.). >>=20 >> Given that J=C3=B6rg stated below that he's OK with using different = tags, I propose that we move forward with using tag 1004 (requested) for = RFC 3339 full-date values and tag char('d') (requested) for integer = number of days relative to the Epoch. If I don't hear objections soon, = I'll publish that draft. >>=20 >> J=C3=B6rg - I'll also add you as a co-author. What affiliation and = e-mail address for you should I use? And is there a URL for a blog or = Webpage you'd also like me to include for you? >>=20 >> Cheers, >> -- Mike >>=20 >> -----Original Message----- >> From: CBOR On Behalf Of Carsten Bormann >> Sent: Wednesday, March 11, 2020 2:09 PM >> To: "Richter, J=C3=B6rg" >> Cc: cbor@ietf.org; Mike Jones = ; Anthony Nadalin = >> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values >>=20 >> On 2020-03-11, at 21:31, Richter, J=C3=B6rg = wrote: >>>=20 >>> (Replying to more than one message here) >>>=20 >>> Carsten Bormann: >>>> Is that a good way forward? >>>=20 >>> I am fine with the suggested procedure. >>=20 >> Great! >>=20 >>>=20 >>>> What I like about Mike's draft is that he references RFC 3339, = which=20 >>>> already is an established specification for how to write dates=20 >>>> textually >>>=20 >>> ISO 8601 also defines this format for dates. It is mentioned in the = "Detailed Semantics" >>> section of my proposal. >>=20 >> ISO 8601 is very "flexible". RFC 3339 uses ISO 8601, but helps by = restricting this to commonly used cases. >> So I think referencing RFC 3339 is strictly better than just naked = ISO 8601. >>=20 >>> Mike Jones: >>>> I'm fine merging J=C3=B6rg's numeric date tag into my draft, = provided that=20 >>>> the result is not a polymorphic tag, in which the value could be = either a number or a string. >>>> We should allocate separate tags for string date and numeric date,=20= >>>> just as tags >>>> 0 and 1 are different, and not polymorphic. >>>=20 >>> I've got the impression that using a polymorphic tag would be no = major problem. >>> We can even specify that decoders might only support one = representation of the tag. >>> I think it would have the same effect if a decoder supports only one = of the two tags. >>> But either way I would have no objections to using two tags. >>=20 >> I'm not sure I like the term "polymorphic" here too much - in any = case, the "value" would be a date. The content could be both text and = number. Tag 1 already does this (integer vs. floating-point), so we = already have to deal with these (i.e., allow applications to not just = say "Tag 1", but "Tag 1 with integer content"). But we did separate Tag = 0 and Tag 1, mostly because the semantics of the value are subtly = different. Are they here? >>=20 >>> Laurence Lundblade: >>>> I'd suggest the numeric date be restricted to integers. No floats,=20= >>>> bignums, decimal fractions. >>>=20 >>> Yes, that was the plan. Only major types 0 and 1. >>=20 >> Finer granularity between dates would be times, which we already = have, so this naturally should be integers. >>=20 >>>> Fractions of days can be represented by tag 0 or tag 1 using hours,=20= >>>> minutes, seconds. 64-bit integer counts of days are large enough. >>>=20 >>> This I don't understand. The proposal only handles whole days as one = number. >>=20 >> Right. Only full days. (The related observation is that these are = always in the local time of some context that is not expressed, which is = rather different from our time tags.) >>=20 >>> Another thing to consider: >>> We should mention that this tag(s) use the proleptic Gregorian=20 >>> calendar. So that dates before the Gregorian calendar have a unique = semantics. >>=20 >> Good point. In 7049bis, we just say: >>=20 >> Negative values (major type 1 and negative floating-point numbers) = are interpreted as determined by the application requirements as there = is no universal standard for UTC count-of-seconds time before = 1970-01-01T00:00Z (this is particularly true for points in time that = precede discontinuities in national calendars). [.] >>=20 >> That is less of a problem on the date-only side (as long as dates = change on local midnight. and not noon), so we may be able to be more = specific. >>=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 >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Thu Apr 23 02:11:15 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 9F6CA3A1817; Thu, 23 Apr 2020 02:11:04 -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=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 pdwSfaDSZ7aH; Thu, 23 Apr 2020 02:11:02 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70077.outbound.protection.outlook.com [40.107.7.77]) (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 E59E83A1875; Thu, 23 Apr 2020 02:10:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PdIR0OFSa8JV2hfyrmh5/A95FWWJJuik+cmb1uNSRfnInYPf7s6bBJH3iK9ULUEQa6oDTzxCKU8DWetXYYNautBDdDuwckNPBu05x36aMJrO0bkZlKn0bSPydRe8FkAn+MjPxCEpBbcd2Zki9un7++B1kUSeXyepi3so0TQxG3SwqFRFdgNGBk0SPmX+bf5+glK9+lPxhT1T9mvk49CMCRCsdC72N/6rRloSmisc3EQO2jwbIrXkm8xqYfMlAy93pigE5P+fSQASOwp8v2rjzeWXop8ucpX6cCH0WHLdknIogYYa8zmY5jbYxg0rcDNgPV2DpijiJyyCLzM/++mf8g== 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=jx0hQt8GDRd37c1Qtcy3/Bvzzd4TC44e4xFSGodBJWg=; b=ByVvPbj98PwRrf/j7e/VA0QAAPgCdd/pzF/r91RjcvNmsq0kBY8XDGVyXdkWybRsNoj2E9fS8T1/rBOXlKp90sac/wauPuGyOJh7gWG8F32Gt2Bjh3K4tigFd+mOjSMR40DHh5OnYD1Ot0MjP3zPmfDaBIxeoq0+gmA/D5ejAE/IhHLpKJxdoCE9EqJgAGg9MFkHmNMR/M+f4vcBkCI84NhhYh2/rHj1+t+xgcGq4cVZchFH3OcVr8aFCM3pXdEwFT4y1qI5D0nQb4Zw/XrfdqHJss2U/IbBBt/FHG7GUDDGZSxoUTeUtUcXc6ZGZf7s1e28JMAL1NuVUDSoni1L9Q== 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=jx0hQt8GDRd37c1Qtcy3/Bvzzd4TC44e4xFSGodBJWg=; b=oOtwy72X2n/59AhcBBdpgHSuNlejhtI2Vc/5RJ/4OHDl9P+7z9GIXFQKhj0Fwxd6tcM8uXlTd0ecHHzt4ydVdmn41ho7DsBl+/Ky2aMQ6vr8CUveppa1ghB2dXXRdMmffvf3voGcGOfedIR/lTQtr5QseHHTl64xjdFU8NiTBNU= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3676.eurprd07.prod.outlook.com (2603:10a6:7:8d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Thu, 23 Apr 2020 09:10:36 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2937.012; Thu, 23 Apr 2020 09:10:36 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIG9mIGRyYWZ0LWpvbmVzLWNi?= =?utf-8?Q?or-date-tag?= Thread-Index: AQHWGU8MatEIlU1iC0ynTVRcHNLC2Q== Date: Thu, 23 Apr 2020 09:10:36 +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.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e2097ba-a930-4b9e-72cd-08d7e7662f8a x-ms-traffictypediagnostic: HE1PR0702MB3676: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03827AF76E 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)(376002)(396003)(346002)(136003)(39860400002)(366004)(71200400001)(8936002)(6486002)(6916009)(2906002)(966005)(4744005)(478600001)(186003)(44832011)(33656002)(6512007)(5660300002)(81156014)(86362001)(2616005)(66476007)(4326008)(64756008)(36756003)(6506007)(66446008)(316002)(66946007)(76116006)(66556008)(26005)(450100002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ibaZiTCnrpk58SZ+VSvh4diESBePUtiTzALvrv6BPP0LALG/ccu7AzSy7u1svHSo7abyaDA8UVPlIO2qxlue5jTmt43xhEVZmwJBh3LBKLOERYNIc4VgF8Hi2AhwwkMcRTD5yoVJ/QquxIRLlv8eImghDN4Q0fNA0iBqzag92Ykd2VpUmUjEXiIKp0Ey2nnFYP2Z4R1rYx9IDxIB4hYDie/c/jK8L+1Fnp3ucLB9RU2hUIn4PgPAGmRsSNGRw7GiwzRXXy8x2ib1dXaAb2WfEUEdmRdL+3EuWty9vpfHhGGa3rm7CsSqB38ikSVYVwpyPZFRVtwAlEdQ/3mTKlXxKEnEOEKw93Fuf3T9nhlYAbK1blYpO6GJFFmQZqJtj/Dl/U027eJOrcDzsYdZemNYRTkD2b15olLyNUppAw1K3lmhwoQgckDAT2FXAWf2wvgOwEO5bxfWCT6AFrbqqCCk6lHz5MSQSEui0uEPywlkj1yVEBbw8vfjUDvxEUFlAKfb2c14QKZfS7YuxRlqaNFwYg== x-ms-exchange-antispam-messagedata: SnhfZzAT5amevIv8Ok3tnMMcx1Ou7OQnL++EJXgxRLVnN1MZD2EUS4+mvmw5jKIWZhFEzi1VYWtvUGKZTVh9IJ7AEsvKgkKI0Uopal7WPf1cHUXNi6NjczhGGMgP5m7XQRqZpwxX9p0/LfIXVNLqIVceMQAP90T5qdiKbCJy3jhSsydODOpHjMRsW6VjxD/NfW3j6mLM+khgj4o5omdw/sh8ayelg8LNzRXBByc8qzkWtZSacf2KjAmSrOHL04j+Q9MUU6N8mHrWjlW0ekIyV3/6seFBP1U7vC/owchXC9JC0IW1jBpS51WpWzrg6GY0IDEj1JgWxdmYFDVhe6P2W9bDtQtfA/qGcrlvDxt/RRnkkLaqgCp0vmRg45jctx83yRZE+S0Th/o0TZsBA1J8wHhc/4NBcAeOcDuvg4XgIXPr+wv0+NjIDaY/zkvstP60vo9avU/VOYsq/QA08o3WX6qJVBoIJ4dW6VNwZEhcC5pmLZlRpb6SWcp780iPx35pJLH71kj8IuWeUbHc8kQDO7iyzhkozVU/BciS94ruWSxbxooBFT3F/PJZe385rzrV66bE/0HAL1zjWyswoFbE/2fBE0vMUgSv8WOoFIkN5Vv+i8MGTXGKIUbOP47nEfZZzD566rh8gGj3YC285yJhCByFCOhKRtd589Twb3ihDNWAYN9cLE6fWuI1yJyozS2RzyqXRJx229NSi/akdEL1GpFP08TdhAitHUmt7QwcsU7SPIrlku1ZsSmPvtXoBH15oR05+YljCZ4IRUYJmYAaQ4YSnTefks+pavA47ym8d0iBx5P9myFgZOM86IkLYSjw 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: 1e2097ba-a930-4b9e-72cd-08d7e7662f8a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 09:10:36.5228 (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: DLQlP+ydIYGIx8c2qJUJ8qzuNyPFISc8aOaySwWE3iyCtg3Z5FyNmUPykf/MKLpxCwesXf9ano1OObAMQPzn11ZIu0GPkZC/z7lbXySK9TI3uFVGN/lTwTjSh8G1sOEt X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3676 Archived-At: Subject: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= 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, 23 Apr 2020 09:11:12 -0000 QXQgdGhlIGxhc3QgaW50ZXJpbSBtZWV0aW5nLCB3ZSBoYWQgaW4tcm9vbSBjb25zZW5zdXMgdG8g YWRvcHQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWNib3ItZGF0ZS10 YWctMDEuDQoNClRoaXMgaXMgYSAyIHdlZWtzIGNvbmZpcm1hdGlvbiBjYWxsIGZvciBhZG9wdGlu ZyB0aGlzIGRyYWZ0IGFzIGEgQ0JPUiB3b3JraW5nIGdyb3VwIGl0ZW0sIGVuZGluZyAyMDIwLTA1 LTA2LiANCg0KSWYgeW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSBpbi1yb29tIGNvbnNlbnN1cyB0 byBhZG9wdCB0aGlzIGFzIGEgV0cgZG9jdW1lbnQsIHBsZWFzZSBzcGVhayB1cCBub3cuIElmIHlv dSBhZ3JlZSB3aXRoIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQsIHlvdSBjYW4gYWxzbyB0ZWxsIHVz Lg0KDQpDQk9SIENoYWlycw0KRnJhbmNlc2NhIGFuZCBKaW0NCg0K From nobody Thu Apr 23 02:12: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 37AE13A1907; Thu, 23 Apr 2020 02:12:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158763314512.10609.5219689019120054163@ietfa.amsl.com> Date: Thu, 23 Apr 2020 02:12:25 -0700 Archived-At: Subject: [Cbor] The CBOR WG has placed draft-jones-cbor-date-tag in state "Call For Adoption By WG Issued" 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: Thu, 23 Apr 2020 09:12:32 -0000 The CBOR WG has placed draft-jones-cbor-date-tag in state Call For Adoption By WG Issued (entered by Francesca Palombini) The document is available at https://datatracker.ietf.org/doc/draft-jones-cbor-date-tag/ Comment: WG adoption call ends 2020-05-06. From nobody Thu Apr 23 02:26:35 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 753E73A17A9; Thu, 23 Apr 2020 02:26:34 -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, 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 paOZXzdYU3BO; Thu, 23 Apr 2020 02:26:33 -0700 (PDT) Received: from mail.pdv-fs.de (mail.pdv-fs.de [213.208.220.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19F23A17A6; Thu, 23 Apr 2020 02:26:32 -0700 (PDT) Received: from mail.pdv-fs.de (unknown [192.168.180.94]) by mail.pdv-fs.de (Postfix) with ESMTPS; Thu, 23 Apr 2020 11:26:30 +0200 (CEST) Received: from EXCHDB1.pdv-fs.de (192.168.180.94) by EXCHDB1.pdv-fs.de (192.168.180.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 23 Apr 2020 11:26:30 +0200 Received: from EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437]) by EXCHDB1.pdv-fs.de ([fe80::6c4a:8b1b:60f4:4437%15]) with mapi id 15.01.1979.003; Thu, 23 Apr 2020 11:26:30 +0200 From: =?utf-8?B?UmljaHRlciwgSsO2cmc=?= To: Francesca Palombini , "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: =?utf-8?B?W0Nib3JdIPCflJQgV29ya2luZyBHcm91cCBBZG9wdGlvbiBvZiBkcmFmdC1q?= =?utf-8?Q?ones-cbor-date-tag?= Thread-Index: AQHWGU9AYemVlBz3SkW31kl7y/dfM6iGbxzA Date: Thu, 23 Apr 2020 09:26:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.185.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TMASE-Version: DDEI-3.5-8.5.1020-25372.006 X-TMASE-Result: 10--3.536400-10.000000 X-TMASE-MatchedRID: 5ZUNNHteWpo96lGguw/2wrxygpRxo469e9edeSuv0xqXBXaJoB9JZ9IF VVzYGjNKnCGS1WQEGtCqNCmMKdufMErptWm6lJ5eC24oEZ6SpSk6XEE7Yhw4FqQ57gNxCxgChMV vTGuG/4VF1iVLFWx5QclPgclSefFzlj3Ty8x2OkEb+NnrrnzwGgZXX8DI70XVFwVtTn8Pj+qqUc paEPPs/FbhgBx8Hi7b X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 X-TMASE-INERTIA: 1-0;;J4gzHMCxkPyYUJl0x8cA1w==;; Archived-At: Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_Working_Group_Adoption_of_draft-jo?= =?utf-8?q?nes-cbor-date-tag?= 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, 23 Apr 2020 09:26:34 -0000 PiBJZiB5b3UgZG8gbm90IGFncmVlIHdpdGggdGhlIGluLXJvb20gY29uc2Vuc3VzIHRvIGFkb3B0 IHRoaXMgYXMgYSBXRw0KPiBkb2N1bWVudCwgcGxlYXNlIHNwZWFrIHVwIG5vdy4gSWYgeW91IGFn cmVlIHdpdGggYWRvcHRpbmcgdGhpcyBkb2N1bWVudCwgeW91DQo+IGNhbiBhbHNvIHRlbGwgdXMu DQoNCkkgYW0gZmluZSB3aXRoIGFkb3B0aW5nIHRoZSBkb2N1bWVudC4NCg0KLSBKw7ZyZw0KDQo= From nobody Mon Apr 27 01:10:02 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 068093A11EB; Mon, 27 Apr 2020 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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.82, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 TVPf3-XEZ-Ak; Mon, 27 Apr 2020 01:09:54 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140049.outbound.protection.outlook.com [40.107.14.49]) (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 6DBE23A11E8; Mon, 27 Apr 2020 01:09:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G5gaSz8Ayn4IRPEI9SyJPpsSQRl0slznVn3pR7VVV/NmGhSWxKaZ2zMnxbaM3g6Pnb8xBkKRgkcicQ1hmar9chz8jgpEo6bPSwBfc574xFSxxa56WkxeUEB3qAUHsvbR2Av5yNCNigYSf8o3lWY2ZD8MJngJbtcmep5z9496ObHTM8TtdDRVcf6vlF+6rloo8O809MFEvmksYxuFfTIYqbMEMgSyyCozy75YRr5rLhAnvKMBHPGLyZrdUd/M5+1UOSxNdbVWB7avAPqEoZOE6kRJHTqWee7rNCVNu8oZGSd+4hfGjGtRGEqYT5mSMuPtuxuufbmrtKMuKWqA8cYT/g== 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=OBV1vv67Ra8cROWkaFnUg/UmpzPsUy6S4q+wOvsDt9o=; b=iSlMrSoEPHEnFkK8IEd6j+BwXGaZ8HL1fQ3xuIT4dc2KaAcm+KY8WzzV/jQbnA4s2GTLqQDaKXgN8xvmM7WVPRVjF+uo7XmkWEIXPvsj4S8qkN8+myuDEzQaGM0OaKdYauVeQR7E93QUIOEQSfDGFVq99YU0iQljHOxGE7Ma17aS34cWERiTyL5B3mmhmAkoqRx1NHCN6zb00Nfsm01KdyPe/3pkC0g/9/t3ZOY1BPCD/6aJNqISP1hPsgntSFwE9pSV84GLoIhVd2NegVSNBweBJoRW52+H1KcANGrYgqwemq7XzQ1rV7T/TAeCDHXhRNqtcJU+OnauRGOwDvZ8RQ== 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=OBV1vv67Ra8cROWkaFnUg/UmpzPsUy6S4q+wOvsDt9o=; b=DZroU/mAnIPpRerCdeSbGr0NGOA4R+OV/iTVdZ3iI5/UF/wuxGjrqHugDi4ZsXn4F5co1Br2fshSL5eQnDpQMGgQJOaDj/zk0gvcBj6PGr8QBnMStcYSffwtp0pyz/EHVYOD6/mazBDSLh2kWylO1spBFux1G2GnQqiTNqFhe2o= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0702MB3596.eurprd07.prod.outlook.com (2603:10a6:7:8c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Mon, 27 Apr 2020 08:09:38 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::f0bb:b1ae:bf22:4526%6]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 08:09:38 +0000 From: Francesca Palombini To: "cbor@ietf.org" CC: "cbor-chairs@ietf.org" Thread-Topic: Minutes interim 2020-04-22 Thread-Index: AQHWHGsyqHe3iPdjf0+FEKlgVqhYHQ== Date: Mon, 27 Apr 2020 08:09:38 +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.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14a189ec-3f61-49b6-8031-08d7ea8254ae x-ms-traffictypediagnostic: HE1PR0702MB3596: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0386B406AA 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)(376002)(346002)(39860400002)(136003)(366004)(396003)(4326008)(478600001)(5660300002)(53546011)(6506007)(44832011)(186003)(966005)(66574012)(71200400001)(450100002)(2906002)(76116006)(36756003)(16799955002)(8936002)(6512007)(6486002)(2616005)(6916009)(26005)(66446008)(33656002)(8676002)(64756008)(66476007)(316002)(81156014)(66556008)(66946007)(86362001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 08Zxp3HX34u7Jxdps9w1DS3yAQEW/kEwT4qWyZisjFel1UEgEZ/OGtDvqCtkXrn67kIBL8qNAfe0kUMZuFij6E3DFTmrASYCiemvoKb0c5Bx0NIJz30CAUHUUrJpUyWrA9a4YNFFe/OEa6mTamfRU9u5Sz0hHdRxAhJqU9LsjHn55CdVmFZie7K5dlOD0XJcFvElyL5+UHOHDrLICjhoM4ErfyIC7TkG2mCVAJ+BMtU2z+eHg/8l9nAsEwet+yEElboqkM5aa2F4F2phh7z4LQiFzQo3t01RY2hLu27cHF9+AsGaR4sPtiSw54b1FsyMSz/Gp5/JvpCNGkzfx8HGBlGEUMnMoAC0qCgWTl+91Hk5A41i1fkHgV5glTZLBZcBRq56xMQdZVc97zRSv4f9Bc9dMeb0ttBuSgJWTUKzRol5z0cQX15zEFFdKdog2Exqd7bzfcscW+V9EbDUll2m28q+6kyXxqjKh3C1Zw+9j5fHPCVJUU2weiLm6e643izLqDbIxCrHJ38+EBFswJ6Hrw== x-ms-exchange-antispam-messagedata: +Ar4GX7jzomN6MFHfevf/TME7nKo8qS1vuHmNQxXNpndtuIcU06tojrbS+3aKXrI3GdPWh3bO5L6CADw19D45pdHAdj7E0Pum+6gW5D1jlNuuHGJywKPqYPZpS2UGHeNN3gJzkhNpUnwLZ/HK1PcaLmE32q8YNBsyxwLsSfw+39d/ET9G/AIFv0Ji2sy4pPXw6PZzyktQ0tX95ZJpf6BICm2GRBu0CYM3U4lL5uMsB9ezmmeWDSiMFH1HDb0iQ7SH99x8uhRJj/A/3780tIIqFqlVjtqTC6Pkf2YulxLlJio/ikR/8GnsGzc3K30cEfEEJq4rdsnPG0l7nQHQ7nzCGYoAHEwzjTwYSiTl9QrGve9ZNcSR+yAI/RlT93VNlvhalvSu9yRMbNxE1Hyfzf8lTMNfAeCN2MwzLj17fWfp9gLZwNqyfxCz1viYe4FvdUCPBy7WIfPiGBMxfha1U7dztM9SILLJs/zpXKgEz+ZYZS97MbGccScxyz8baOP1MdE76PtFIHtRjXTHlVcSo4hwpOTaioB1A2xiBEd/WkGgk3gwzfi3r4W7nYBqG2l2Rg+GRDiWBzeHtpMv5Ndy/blIAwWBjqXuL/MkXLDpfK1sIAFIlcc2X9T+vIqJazoFffL/OM1fnhi3go6QyMLqBVgjFTI/B34IvgMAc4Q8EGnV0I1ravSQQHlnUnMmSrarrrcEBk1GR2iFCZLCaTYWGTzECUaq/S6Elxa9/jdSZOHjSfZ22nXpHfX5xI6ThBJYmHTNA4v+lLXCALBGlHoNfXtSsqgZ7tYUzI0JroV2ByS/t6R78QJD7ZUvdba6o7Cltsv 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: 14a189ec-3f61-49b6-8031-08d7ea8254ae X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 08:09:38.2365 (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: 2Pd1AB9r+T6VEB32oKgQWt6kl7bI1m1oVbFXku751hcleYbKfDQts9oD6fYM4lofGAZNBiv7TrxHItwW5XfBZSXGfrOfqdxz7o1wbKP6p3sneNOXS8ze8QFZ9sWbuaxW X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3596 Archived-At: Subject: [Cbor] Minutes interim 2020-04-22 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, 27 Apr 2020 08:10:00 -0000 SGksDQoNClRoZSBtaW51dGVzIGhhdmUgYmVlbiBwb3N0ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jvci0wNy9tYXRlcmlhbHMvbWludXRlcy1p bnRlcmltLTIwMjAtY2Jvci0wNy0yMDIwMDQyMjE3MDAudHh0DQpQbGVhc2UgbGV0IHRoZSBjaGFp cnMga25vdyBpZiB5b3UgYmVsaWV2ZSBzb21ldGhpbmcgd2FzIGluY29ycmVjdGx5IGNhcHR1cmVk Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMjIvMDQvMjAyMCwgMTA6NDgsICJGcmFu Y2VzY2EgUGFsb21iaW5pIiA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KDQogICAgSGksDQoNCiAgICBSZW1pbmRlciB0aGF0IHdlIGFyZSBoYXZpbmcgYW4gaW50ZXJp bSBsYXRlciB0b2RheS4gVGhlIGRyYWZ0IGFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQ6IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMjAtY2Jvci0wNy9tYXRlcmlh bHMvYWdlbmRhLWludGVyaW0tMjAyMC1jYm9yLTA3LXNlc3NhDQoNCiAgICBXZWJleCBkZXRhaWxz Og0KICAgIFdlYmV4OiBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjA1 YzQ3YTlhNDE4MTc5ZTNlODEwYTE1MWRjYjI1YTkgDQogICAgTWVldGluZyBudW1iZXIgKGFjY2Vz cyBjb2RlKTogNjQ3IDgzNiA0MjAgDQogICAgTWVldGluZyBwYXNzd29yZDogZW1IcmlnQzIySzQN Cg0KICAgIEFsc28sIG1pbnV0ZXMgZnJvbSBsYXN0IG1lZXRpbmcgaGF2ZSBiZWVuIHVwbG9hZGVk LCBsZXQgdGhlIGNoYWlycyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50czogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAyMC1jYm9yLTA2L21hdGVyaWFs cy9taW51dGVzLWludGVyaW0tMjAyMC1jYm9yLTA2LTIwMjAwNDA4MTcwMC50eHQgDQogICAgQW5k IHJlY29yZGluZ3M6IGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9QVpOVnc5MWdacDAm ZmVhdHVyZT15b3V0dS5iZSANCg0KICAgIFRoYW5rcywNCiAgICBGcmFuY2VzY2ENCg0KICAgIE9u IDExLzAzLzIwMjAsIDIxOjMxLCAiQ0JPUiBvbiBiZWhhbGYgb2YgSUVTRyBTZWNyZXRhcnkiIDxj Ym9yLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGllc2ctc2VjcmV0YXJ5QGlldGYub3Jn PiB3cm90ZToNCg0KICAgICAgICBUaGUgQ29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0 aW9uIE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zIChjYm9yKSBXb3JraW5nIEdyb3VwIHdpbGwg aG9sZA0KICAgICAgICBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uIDIwMjAtMDQtMjIgZnJv bSAxNzowMCB0byAxODowMCBFdXJvcGUvUGFyaXMuDQoNCiAgICAgICAgQWdlbmRhOg0KICAgICAg ICAoTm8gYWdlbmRhIHN1Ym1pdHRlZCkNCg0KICAgICAgICBJbmZvcm1hdGlvbiBhYm91dCByZW1v dGUgcGFydGljaXBhdGlvbjoNCiAgICAgICAgV2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8g dGhlIENCT1IgbWFpbGluZyBsaXN0IGJlZm9yZSBlYWNoIGNhbGwuDQoNCiAgICAgICAgVGhlIENC T1Igd29ya2luZyBncm91cCB3aWxsIGhhdmUgY29uZmVyZW5jZSBjYWxscyBydW5uaW5nIGV2ZXJ5 IHR3bw0KICAgICAgICB3ZWVrcyB0aHJvdWdoIHRoZSBlbmQgb2YgSnVseSAyMDIwICh1bnRpbCBJ RVRGIDEwOCkuDQoNCiAgICAgICAgRGF5OiBldmVyeSBvdGhlciBXZWRuZXNkYXkgYmVnaW5uaW5n IG9uIDggQXByaWwNCiAgICAgICAgRGF0ZXM6IDgsIDIyIEFwcjsgNiwgMjAgTWF5OyAzLCAxNyBK dW47IDEsIDE1IEp1bA0KICAgICAgICBUaW1lOiAxNzowMCB0byAxODowMCBDRVQvQ0VTVA0KDQog ICAgICAgIFdlIHdpbGwgdXNlIHRoZSB3b3JraW5nIGdyb3VwIFdlYkV4IGZvciB0aGUgY2FsbHMu IFRoZSBJRVRGIFdlYkV4DQogICAgICAgIGFjY291bnQgZG9lcyBub3QgYWxsb3cgSW50ZXJuYXRp b25hbCBkaWFsaW5nIG5vciBVUyB0b2xsIGZyZWUgKCI4MDAiDQogICAgICAgIG51bWJlcnMpLCBi dXQgeW91IGNhbiB1c2UgdGhlIFdlYkV4IGFwcCB0byBjb25uZWN0IHlvdXIgZGV2aWNlIGF1ZGlv LA0KICAgICAgICBhbmQgdGhlcmUncyBhbHNvIHRoZSBvcHRpb24gb2YgY29ubmVjdGlvbiBkaXJl Y3RseSBmcm9tIHlvdXIgYnJvd3Nlcg0KICAgICAgICBpZiB5b3VyIGJyb3dzZXIgc3VwcG9ydHMg aXQuDQoNCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgQ0JPUiBtYWlsaW5nIGxpc3QNCiAgICAgICAgQ0JPUkBpZXRmLm9yZw0K ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nib3INCg0KDQo=