From nobody Tue May 1 15:33:35 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46D12EA67 for ; Tue, 1 May 2018 15:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkNhi9bk1wD5 for ; Tue, 1 May 2018 15:33:24 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 3539D12EAE0 for ; Tue, 1 May 2018 15:33:24 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id i194-v6so9176476pgd.0 for ; Tue, 01 May 2018 15:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ksr9KqDDadvuVETiWkwNf+qZ11OlZTV7/ig3IoHK6Lc=; b=DLFxzd02X8cMCTgzvQn9e8ZZpQT0KFVMn1RszWhY2YJ0wurm+s6YLVk4nnu7LOdyQK VzkrFgRH+0LduVZByO4DYm5HWByD66m64hf4kTsj0r++vArPMW0XgqkOkFgn1aa9umTm bfHVZTjSGH8Xb2HK30pZa861DjYhjx2OByONZ/Ha3P9+upDN3RwDv/otv4MSbJYRVgI0 /cxIRu1PsPNHubV89IzloJtNfwhKHDIQAcxruljJqADFCOO81z1V7xFoDrzU/NX7DlWg Mi0zmjy3IEhLM2wAl/SPQsQsncNbjwqP2y2RmcMybm4bN2qDsKDGNLmpKU++cTPa3xG4 Q3Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ksr9KqDDadvuVETiWkwNf+qZ11OlZTV7/ig3IoHK6Lc=; b=mlqjMSp8JEHtx1HD0l1HsnmVsLdRAWnylmjXnGCy6LxIlESEUPuzejxSXG29pHaSMq F6y6JrDadCRTZYio6p6ZlDN75VS0ttjBtjYUH/jpR7CPIc9IpEeZIwuX0uYMEjvjEYKn NjlfHvhNBPk/hYII69rWqIWh05KNfp1TGfbcxhjfyGa9krq85vUfBkvdMbaKvw79MG60 B22Mt08hGK3jhARxPBEbAw9yRCPMTLCmGhmCayIKUTl5WMKGTn/0+Vncr2bgl4R2UXg/ k4I9h2kS4oB95Hzu1wNhPG0t11AXrNRqoC5DET6TTt9vXcj5dWuZZ9Z2xvNdyZv/j1J9 vyaA== X-Gm-Message-State: ALQs6tC0ZFhc5uOgnX8bv6n/aCDCwVXUWq445kFS2pY6sBJTvtZ6zrui vcdx/E/nt5fFOLkIV/q5/OsPQA== X-Google-Smtp-Source: AB8JxZpdakvYNtekIzO+EBXfmwIbRH68n0lY+E8oHdy/yEikSN9rMAnrjGrcOwwp6+XqRkdTT1VPcw== X-Received: by 2002:a17:902:6902:: with SMTP id j2-v6mr12231986plk.313.1525214003450; Tue, 01 May 2018 15:33:23 -0700 (PDT) Received: from [172.24.16.153] ([202.36.244.180]) by smtp.gmail.com with ESMTPSA id r20sm22919851pff.152.2018.05.01.15.33.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 15:33:22 -0700 (PDT) Sender: Brian Carpenter To: Burt Harris , "cbor@ietf.org" References: From: Brian E Carpenter Message-ID: Date: Wed, 2 May 2018 10:33:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 22:33:34 -0000 On 01/05/2018 08:43, Burt Harris wrote: > After reading RFC 7049, it seemed apparent to me that the JSON string type would generally be encoded in CBOR as major type 3 (text string). > > However reviewing section 4.2, which is specifically about converting JSON to CBOR, nowhere does this rule seem stated explicitly. I would normally not have considered this a problem, but I encountered examples in one of the tag definition documents uses where the author seems to interpret the RFC as saying that CBOR major type 2 (byte string) may be used as an alternative. > > Take for example, the 3-charactar JSON content "1" (with quotes included in the JSON.) I've been surprised about how adamant the other author has been that this may be encoded as 41 31, when it seemed clear to me that 61 31 was the canonical encoding. > > I therefor wonder if it might be a good idea to add language to the CBOR bis document saying that JSON strings should always be encoded as CBOR major type 3, and that in general major type 2 would be unexpected in the result of a JSON to CBOR translation. That statement seems OK. However, "explicitly prohibited" sounds wrong to me, because there might be cases where it was reasonable to send a piece of text that just happens to be JSON as plain text. In that case there is no "translation" from JSON to CBOR; the application is just using CBOR to transport a piece of text. Brian From nobody Wed May 2 08:04:23 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB5712D88D for ; Wed, 2 May 2018 08:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDd7FES-l6GJ for ; Wed, 2 May 2018 08:04:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007102.outbound.protection.outlook.com [40.92.7.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D2312E856 for ; Wed, 2 May 2018 08:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XwS6JzTpwz57AII+oz2lpcJgLOqx2x574hKdO1nVC0w=; b=axSt0lFx69ateiMM9vrN25UJ+AFc4DNItJAZZ4sFjIQvRuPRCn4v1wvFc5DMrb/dH5jWJJT+Oy1cXMusEREWO+1AhPMs3Ieb5IG5OLAAHIFZCNNQZRmaZPSsiPWixQ0R8oPaAwqrboPNXe3AWHM0OPBCiru2FpvvktPQxAgUYYeZ/k76GEOXzfBoHm2TIwnDPL7c911WzImYIanUtBIQT/HAs+0yuB9v++EcXzLwYJzOw8xNuuq4Bh+xTofxJKpxkP0A1SpZevcTWlX02gFAUSA9JHR3NN7oSjMLdewH7v7xFkJeWCivJRcogfxUlXob9/VFrVZ84KLB2gFIiBaOEA== Received: from DM3NAM03FT055.eop-NAM03.prod.protection.outlook.com (10.152.82.55) by DM3NAM03HT210.eop-NAM03.prod.protection.outlook.com (10.152.83.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.696.11; Wed, 2 May 2018 15:04:03 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.82.54) by DM3NAM03FT055.mail.protection.outlook.com (10.152.83.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.13 via Frontend Transport; Wed, 2 May 2018 15:04:03 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1%18]) with mapi id 15.20.0696.023; Wed, 2 May 2018 15:04:03 +0000 From: Burt Harris To: Brian E Carpenter , "cbor@ietf.org" Thread-Topic: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? Thread-Index: AdPgwRs737ku8ludTkugZp5tVfTGkQA20wuAACDyyKA= Date: Wed, 2 May 2018 15:04:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:ADADF34A623B6159CF93F7535EA350C114FAB1993D74125F5C0DA23B7F57C5E3; UpperCasedChecksum:27F30CA7068C7B618330F1FAEB23ABDF63452772967CF68604B426377E66B2D7; SizeAsReceived:7168; Count:45 x-tmn: [tk/06RNUpYh01ItgSPVmV6q0J7LArQnV] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM03HT210; 7:t3+c6hSsQafshK7Zewds2XXZAYvINSTNMEe40BCJVIBSWbhPU3qJgjdOntwnhRVxj14a64e4nbqGzccejGA4WUex2/9fbVpDehuugCLIhrHin0z8iZJIT40bzLRiQ+FY+hQFIYNCSDgxD/z66IA5ev5Qlaa50ahhIHM7mfvbq0EGnwDPHDPq0LgpHfoMmIs2A/B/Er2Fqn0W97Fhww2A7iURQ2T/J+YAQG/ocBOZXkOC8Jrj9wrLM0dbb7BY4luO x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:DM3NAM03HT210; x-ms-traffictypediagnostic: DM3NAM03HT210: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM03HT210; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM03HT210; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT210; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: 2Qj9uLlgMSMBEAk2pJCR2wfIaZ5/5E/HUkIMki0+CzYrbzxwHe2OyqXYZSf7FJ/uLEE9Ig+Xd9it7Z2XNiA6zh1LifZFz9wDn3Inpi8y1mhd0rW8HDiAx3eWIS5tRdqafn8gEYXI8TefAUpoB0r9SZUNtib57KsbuQidLigGbKFu4ujRSDs1TpDY0Utsle0+ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e3586c52-80de-426f-85be-08d5b03df171 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: e3586c52-80de-426f-85be-08d5b03df171 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2018 15:04:03.2254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT210 Archived-At: Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 15:04:10 -0000 T24gMjAxOC0wNS0wMSBCcmlhbiBDYXJwZW50ZXIgd3JvdGU6DQoNCj4gVGhhdCBzdGF0ZW1lbnQg c2VlbXMgT0suIEhvd2V2ZXIsICJleHBsaWNpdGx5IHByb2hpYml0ZWQiIHNvdW5kcyB3cm9uZyB0 byBtZSwgYmVjYXVzZSB0aGVyZSBtaWdodCBiZSBjYXNlcyB3aGVyZSBpdCB3YXMgcmVhc29uYWJs ZSB0byBzZW5kIGEgcGllY2Ugb2YgdGV4dCB0aGF0IGp1c3QgaGFwcGVucyB0byBiZSBKU09OIGFz IHBsYWluIHRleHQuIA0KPiBJbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8gInRyYW5zbGF0aW9uIiBm cm9tIEpTT04gdG8gQ0JPUjsgdGhlIGFwcGxpY2F0aW9uIGlzIGp1c3QgdXNpbmcgQ0JPUiB0byB0 cmFuc3BvcnQgYSBwaWVjZSBvZiB0ZXh0Lg0KDQpUaGFua3MgQnJpYW4sIHllcyBteSBhdHRlbXB0 IHRvIHN1bW1hcml6ZSBpbiB0aGUgc3ViamVjdCBsaW5lIGNvdWxkIHVzZSByZWZpbmVtZW50LCB1 c2luZyBsYW5ndWFnZSBkZWZpbmVkIGluIFJGQyAyMTE5LiAgIEkgdGhpbmsgd2UgaGF2ZSB0aGUg c2FtZSBpZGVhIGluIG1pbmQuICAgV2hhdCBJJ20gc3VnZ2VzdGluZyBpcyBhZGRpbmcgYSBzZW50 ZW5jZSB0byBSRkMgNzA0OSBzZWN0aW9uIDQuMiAqKkNvbnZlcnRpbmcgZnJvbSBKU09OIHRvIENC T1IqKiBzYXlpbmc6DQoNCiAgICBKU09OIHN0cmluZ3MgTVVTVCBiZSByZXByZXNlbnRlZCBhcyBD Qk9SIHRleHQgc3RyaW5ncyAobWFqb3IgdHlwZSAyKSBhbmQgU0hPVUxEIGJlIHJlcHJlc2VudGVk IGluIHRoZSBzaG9ydGVzdCBmb3JtIGFsbG93ZWQuDQoNCldoYXQgInBsYWluIHRleHQiIG1lYW5z IGluIHlvdXIgY29tbWVudCBzZWVtcyBhIGJpdCBhbWJpZ3VvdXMuICAgSWYgc29tZW9uZSAqZW5j b2RlcyB0ZXh0KiBhcyBDQk9SIGFuZCB0aGF0IGhhcHBlbnMgdG8gYmUgdmFsaWQgSlNPTiwgZS5n LiB0aHJlZSBjaGFyYWN0ZXJzIGBbMV1gLCB0aGUgQ0JPUiBvdXRwdXQgU0hPVUxEIGJlIHRoZSBm b2xsb3dpbmcgNCBieXRlczoNCg0KICAgIDYzICAgICAgICAjIHRleHQoMykNCiAgICAgICA1QjMx NUQgIyAiWzFdIiANCg0KV2hpbGUgaWYgc29tZW9uZSAqY29udmVydHMqIHRoZSBzYW1lIDMtY2hh cmFjdGVyICBKU09OIHRvIENCT1IsIHRoZSBleHBlY3RlZCBieXRlcyB3b3VsZCBiZToNCg0KICA4 MSAgICAjIGFycmF5KDEpDQogICAgIDAxICMgdW5zaWduZWQoMSkNCg0KV2hhdCBNVVNUIE5PVCBi ZSBvdXRwdXQgd291bGQgYmU6DQoNCiAgICA0MyAgICAgICAgIyBieXRlcygzKQ0KICAgICAgIDVC MzE1RCAjICJbMV0iDQogDQpCZWNhdXNlIHRoZSBpbnB1dCB3YXMgc3BlY2lmaWVkIHRvIGJlIHRl eHQgKG5vdCBieXRlcy4pDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QnJpYW4gQ2FycGVudGVyIDxiZWNhcnBlbnRlcjQ2QGdtYWlsLmNvbT4gT24gQmVoYWxmIE9mIEJy aWFuIEUgQ2FycGVudGVyDQpTZW50OiBUdWVzZGF5LCBNYXkgMSwgMjAxOCAzOjMzIFBNDQpUbzog QnVydCBIYXJyaXMgPGJ1cnRfaGFycmlzQGhvdG1haWwuY29tPjsgY2JvckBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtDYm9yXSBTaG91bGQgZW5jb2Rpbmcgb2YgSlNPTiBzdHJpbmdzIGFzIENCT1Ig bWFqb3IgdHlwZSAyIGJlIGV4cGxpY2l0bHkgcHJvaGliaXRlZD8NCg0KT24gMDEvMDUvMjAxOCAw ODo0MywgQnVydCBIYXJyaXMgd3JvdGU6DQo+IEFmdGVyIHJlYWRpbmcgUkZDIDcwNDksIGl0IHNl ZW1lZCBhcHBhcmVudCB0byBtZSB0aGF0IHRoZSBKU09OIHN0cmluZyB0eXBlIHdvdWxkIGdlbmVy YWxseSBiZSBlbmNvZGVkIGluIENCT1IgYXMgbWFqb3IgdHlwZSAzICh0ZXh0IHN0cmluZykuICAg DQo+IA0KPiBIb3dldmVyIHJldmlld2luZyBzZWN0aW9uIDQuMiwgd2hpY2ggaXMgc3BlY2lmaWNh bGx5IGFib3V0IGNvbnZlcnRpbmcgSlNPTiB0byBDQk9SLCBub3doZXJlIGRvZXMgdGhpcyBydWxl IHNlZW0gc3RhdGVkIGV4cGxpY2l0bHkuICAgSSB3b3VsZCBub3JtYWxseSBub3QgaGF2ZSBjb25z aWRlcmVkIHRoaXMgYSBwcm9ibGVtLCBidXQgSSBlbmNvdW50ZXJlZCBleGFtcGxlcyBpbiBvbmUg b2YgdGhlIHRhZyBkZWZpbml0aW9uIGRvY3VtZW50cyA8aHR0cHM6Ly9ldXIwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZjYm9yLnNjaG1vcnAuZGUl MkZzdHJpbmdyZWYmZGF0YT0wMiU3QzAxJTdDJTdDNWQ1NmIyNDlkZjQ1NGFjN2E2NGIwOGQ1YWZi MzhjZjglN0M4NGRmOWU3ZmU5ZjY0MGFmYjQzNWFhYWFhYWFhYWFhYSU3QzElN0MwJTdDNjM2NjA4 MTA4MDQ5NTIzNzI4JnNkYXRhPUNLZ3dqbm0yMWslMkY3JTJCUEtnTlBZSEZhJTJCc1JsV0xWSUdC Z3lZNFBKS0dMdTglM0QmcmVzZXJ2ZWQ9MD4gdXNlcyB3aGVyZSB0aGUgYXV0aG9yIHNlZW1zIHRv IGludGVycHJldCB0aGUgUkZDIGFzIHNheWluZyB0aGF0IENCT1IgbWFqb3IgdHlwZSAyIChieXRl IHN0cmluZykgbWF5IGJlIHVzZWQgYXMgYW4gYWx0ZXJuYXRpdmUuICANCj4gDQo+IFRha2UgZm9y IGV4YW1wbGUsIHRoZSAzLWNoYXJhY3RhciBKU09OIGNvbnRlbnQgIjEiICh3aXRoIHF1b3RlcyBp bmNsdWRlZCBpbiB0aGUgSlNPTi4pICAgICBJJ3ZlIGJlZW4gc3VycHJpc2VkIGFib3V0IGhvdyBh ZGFtYW50IHRoZSBvdGhlciBhdXRob3IgaGFzIGJlZW4gdGhhdCB0aGlzIG1heSBiZSBlbmNvZGVk IGFzIDQxIDMxLCB3aGVuIGl0IHNlZW1lZCBjbGVhciB0byBtZSB0aGF0IDYxIDMxIHdhcyB0aGUg Y2Fub25pY2FsIGVuY29kaW5nLiAgIA0KPiANCj4gSSB0aGVyZWZvciB3b25kZXIgaWYgaXQgbWln aHQgYmUgYSBnb29kIGlkZWEgdG8gYWRkIGxhbmd1YWdlIHRvIHRoZSBDQk9SIGJpcyBkb2N1bWVu dCBzYXlpbmcgdGhhdCBKU09OIHN0cmluZ3Mgc2hvdWxkIGFsd2F5cyBiZSBlbmNvZGVkIGFzIENC T1IgbWFqb3IgdHlwZSAzLCBhbmQgdGhhdCBpbiBnZW5lcmFsIG1ham9yIHR5cGUgMiB3b3VsZCBi ZSB1bmV4cGVjdGVkIGluIHRoZSByZXN1bHQgb2YgYSBKU09OIHRvIENCT1IgdHJhbnNsYXRpb24u DQoNClRoYXQgc3RhdGVtZW50IHNlZW1zIE9LLiBIb3dldmVyLCAiZXhwbGljaXRseSBwcm9oaWJp dGVkIiBzb3VuZHMgd3JvbmcgdG8gbWUsIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgY2FzZXMgd2hl cmUgaXQgd2FzIHJlYXNvbmFibGUgdG8gc2VuZCBhIHBpZWNlIG9mIHRleHQgdGhhdCBqdXN0IGhh cHBlbnMgdG8gYmUgSlNPTiBhcyBwbGFpbiB0ZXh0LiBJbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8g InRyYW5zbGF0aW9uIiBmcm9tIEpTT04gdG8gQ0JPUjsgdGhlIGFwcGxpY2F0aW9uIGlzIGp1c3Qg dXNpbmcgQ0JPUiB0byB0cmFuc3BvcnQgYSBwaWVjZSBvZiB0ZXh0Lg0KDQogICBCcmlhbg0K From nobody Wed May 2 19:07:17 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D90127599 for ; Wed, 2 May 2018 19:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C67cygt04ho6 for ; Wed, 2 May 2018 19:07:14 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 51F7B1274D2 for ; Wed, 2 May 2018 19:07:14 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id w129so7950571pfd.3 for ; Wed, 02 May 2018 19:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vTFhuDIjcZaVVCmV/+hVjUKHOpN72u+yYAr+aUi6SWM=; b=uhaVHOctCHu+/VP/jAL6wu8xwNa5yJp0oVCAUeBPk+fulYfH0Uy1cE1lqexCUbV1PV CqdQ1/2oh5wuCEVLiNiPRRhiuKHkXvAXVXXjYngo+gruijBo5PSUhen0f5dyM49pTEfC vExuch4s9jCWk5dvPKTTT3Ns/YBeaNw96rp1dt0wvUlvK/tbxke39NK9tyunx4xcQq+j XO/ELGOoYjAD/Ks88eEHTmuOdw4pLz52D8bZbhOKs0XDuTq086wvMnY6HrxMfD1lAuhl OCNBsIhvYnDFanbrbSNQN/BvA1LvD/XsnaZUSoxXzLnNfCqPIZ8ORlis7x/rqD/uBdlT Pe+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vTFhuDIjcZaVVCmV/+hVjUKHOpN72u+yYAr+aUi6SWM=; b=Vu+ActQcDRsniSjOHENrQVK4gH2z/cmgrG0X93bvtMZasqndHlp3OCfA7HFrMQZ3aQ gMmdJ8a04IlUhTsujEJnUj/hnWzogtgnj4U3dTcKC7WVcJgKsaKyBKrfuw3ZI/G4hab3 73KHlkaluD+8cv8+vhDmbRc/wziV+ZI4NiLc83CjKje9aEBWHNGErITYIubve7fqI0TL PbcxZhMBBIWqR5bzPEpumRm5D2a44LZNh3ZJCuhvUKUFExJeciP88HvrcCC3FJdqB21r 9ZR6VQv8J8v5y7MDhlAlirVPHZC5IikWD5Zr+aqBiCydvj43r5E/GsgPSESaGlC3QvmG ZP5g== X-Gm-Message-State: ALQs6tD3OkHz3NzuEYhRISn9ujS4YM20/3pW3TjLln9YuJA7JxLEvlg4 iD6y6G70KHFNmKSLIe1xznqsVQ== X-Google-Smtp-Source: AB8JxZpLi/2Fw9Bd5i85doA+k2Y+aSKi9Ii3g7nexYWfOvAaYvHlDGypLbyVSwZ0oL0V1AnitcgT2w== X-Received: by 2002:a63:b94a:: with SMTP id v10-v6mr17898705pgo.372.1525313233693; Wed, 02 May 2018 19:07:13 -0700 (PDT) Received: from [192.168.178.26] ([118.149.104.73]) by smtp.gmail.com with ESMTPSA id e8sm498679pfd.168.2018.05.02.19.07.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 19:07:12 -0700 (PDT) Sender: Brian Carpenter To: Burt Harris , "cbor@ietf.org" References: From: Brian E Carpenter Message-ID: <449c3166-05fb-2653-b4fc-1fa47e46654c@gmail.com> Date: Thu, 3 May 2018 14:07:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 02:07:16 -0000 Yes, I think we agree. Regards Brian On 03/05/2018 03:04, Burt Harris wrote: > On 2018-05-01 Brian Carpenter wrote: > >> That statement seems OK. However, "explicitly prohibited" sounds wrong to me, because there might be cases where it was reasonable to send a piece of text that just happens to be JSON as plain text. >> In that case there is no "translation" from JSON to CBOR; the application is just using CBOR to transport a piece of text. > > Thanks Brian, yes my attempt to summarize in the subject line could use refinement, using language defined in RFC 2119. I think we have the same idea in mind. What I'm suggesting is adding a sentence to RFC 7049 section 4.2 **Converting from JSON to CBOR** saying: > > JSON strings MUST be represented as CBOR text strings (major type 2) and SHOULD be represented in the shortest form allowed. > > What "plain text" means in your comment seems a bit ambiguous. If someone *encodes text* as CBOR and that happens to be valid JSON, e.g. three characters `[1]`, the CBOR output SHOULD be the following 4 bytes: > > 63 # text(3) > 5B315D # "[1]" > > While if someone *converts* the same 3-character JSON to CBOR, the expected bytes would be: > > 81 # array(1) > 01 # unsigned(1) > > What MUST NOT be output would be: > > 43 # bytes(3) > 5B315D # "[1]" > > Because the input was specified to be text (not bytes.) > > > > -----Original Message----- > From: Brian Carpenter On Behalf Of Brian E Carpenter > Sent: Tuesday, May 1, 2018 3:33 PM > To: Burt Harris ; cbor@ietf.org > Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? > > On 01/05/2018 08:43, Burt Harris wrote: >> After reading RFC 7049, it seemed apparent to me that the JSON string type would generally be encoded in CBOR as major type 3 (text string). >> >> However reviewing section 4.2, which is specifically about converting JSON to CBOR, nowhere does this rule seem stated explicitly. I would normally not have considered this a problem, but I encountered examples in one of the tag definition documents uses where the author seems to interpret the RFC as saying that CBOR major type 2 (byte string) may be used as an alternative. >> >> Take for example, the 3-charactar JSON content "1" (with quotes included in the JSON.) I've been surprised about how adamant the other author has been that this may be encoded as 41 31, when it seemed clear to me that 61 31 was the canonical encoding. >> >> I therefor wonder if it might be a good idea to add language to the CBOR bis document saying that JSON strings should always be encoded as CBOR major type 3, and that in general major type 2 would be unexpected in the result of a JSON to CBOR translation. > > That statement seems OK. However, "explicitly prohibited" sounds wrong to me, because there might be cases where it was reasonable to send a piece of text that just happens to be JSON as plain text. In that case there is no "translation" from JSON to CBOR; the application is just using CBOR to transport a piece of text. > > Brian > From nobody Thu May 3 02:19:26 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7042124207 for ; Thu, 3 May 2018 02:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4ifwIvbTyXe for ; Thu, 3 May 2018 02:19:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BCC124235 for ; Thu, 3 May 2018 02:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w439JEdF020980; Thu, 3 May 2018 11:19:14 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40c8jG25rdzDWqk; Thu, 3 May 2018 11:19:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 3 May 2018 11:19:13 +0200 Cc: Brian E Carpenter , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 547031952.066823-7f5507bfd366e2cb23b2aa1a83511d39 Content-Transfer-Encoding: quoted-printable Message-Id: <1B9DE54D-260C-4F9F-B49E-4E136837ABBC@tzi.org> References: To: Burt Harris X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 09:19:26 -0000 Hi Burt, thank you for pointing out the need for a clarification here. Have you had some conversation with the author of the 256/25 tag spec? On May 2, 2018, at 17:04, Burt Harris wrote: >=20 > JSON strings MUST be represented as CBOR text strings (major type = 2) and SHOULD be represented in the shortest form allowed. 4.2 assumes that this is all obvious, except for numbers. Maybe we should add a table providing the mapping for all types, not = just for text strings? The recommendation for the shortest form also applies to the other = types, as well, no? Note that the entirety of Section 4 is meant to be non-normative, so = using RFC 2119 language would be confusing. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 3 08:27:06 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60A512D87E for ; Thu, 3 May 2018 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKGCdbihsAL5 for ; Thu, 3 May 2018 08:27:01 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000016.outbound.protection.outlook.com [40.92.0.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDA7126C83 for ; Thu, 3 May 2018 08:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FwxcCPC505tJo+sZ1AqetkMPQvXQC58FlHab3dYqGkw=; b=YNqcA+o31HUBdZA+viZ9ydCt0h8ExkW19mNNqKS4DKSKfHPcpJLFBIza4HBrwVlLBapVIvIOID/82Fldj0UIRrukfZkByJqXtkPOpcTUdiyRUl62p3u0WGXGaKTz1uJs8XMBPtVfn9THD6ik2vfJV60KJkkjbiG5lonEmnnEl5kByaBAU4AMbadUkm9kER8dDLEVt/PrWwJKu45LXy+tQumAhhcM+0ll+R66na6UfBloftdf1y9xuvkvWs4bQ5LlevMVGZLDcdIWXhdHRAOX4DtrHP2vO7hzPH9jcX8u4ypy2XjlZvrE9jZranCoatcKTNiNenfaJ0rjSoCNFkemDQ== Received: from BN3NAM01FT038.eop-nam01.prod.protection.outlook.com (10.152.66.57) by BN3NAM01HT049.eop-nam01.prod.protection.outlook.com (10.152.66.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.13; Thu, 3 May 2018 15:26:59 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.66.56) by BN3NAM01FT038.mail.protection.outlook.com (10.152.67.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.715.13 via Frontend Transport; Thu, 3 May 2018 15:26:59 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::44ac:6850:a8cf:78f1%18]) with mapi id 15.20.0696.023; Thu, 3 May 2018 15:26:59 +0000 From: Burt Harris To: Carsten Bormann CC: Brian E Carpenter , "cbor@ietf.org" Thread-Topic: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? Thread-Index: AdPgwRs737ku8ludTkugZp5tVfTGkQA20wuAACDyyKAAJ+aegAAM1GBQ Date: Thu, 3 May 2018 15:26:59 +0000 Message-ID: References: <1B9DE54D-260C-4F9F-B49E-4E136837ABBC@tzi.org> In-Reply-To: <1B9DE54D-260C-4F9F-B49E-4E136837ABBC@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:28DFC356A6A7AB565039696687F9097E6D7BF9842F4322631A36AC4DAE41EAB2; UpperCasedChecksum:25F18EA50821744540300DE8DD3C6262D10105374E27CC462A88EB290B0F26D3; SizeAsReceived:7346; Count:46 x-tmn: [WbG/EIEJx6ErskCVfP6J2i/ED0hcbDnR] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT049; 7:7PD2oHh+BiKsxquY0u0uOtYHgvmuopENRCjtXnKQGWPi2R6Cxt8o5ZFBtyotH9pTiRh1DI2Om8hktPMYmMCM7OAoEcsDTMlCdxZr/E/zYZhK0vJD1PjTIJ8iO8MVtv201cxFfAbX+//UfE1Rm35hpIQ/kU1IbZ21suCuJCxJuHaAObb+FCI5K7UdTBDskf9qpgvzGsPUyDWV8FLcjunfmNuPByd21lwriYDRCpnO/XiXhFMdGvBuFLonU7Cl6OxL x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BN3NAM01HT049; x-ms-traffictypediagnostic: BN3NAM01HT049: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT049; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT049; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT049; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: KLoOedVqYZHy9B4279lWbXiimj7tLh2wNF1185cxsFvOd0uGSvHCm4J9gdpIFSHXrl27Irhbz8dC9bwIMxHkyTk2TWNzqsKbD3n90gr9/zray4x4W8g/8p/41gywYDpEWBBMtQmCstCWxLHMiPsmRsCMOg8R+ZaluLrWveTE+a6pIQo4s2zbI/fXYWAMwIeL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 784357ab-07dc-43f0-701d-08d5b10a501b X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 784357ab-07dc-43f0-701d-08d5b10a501b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 15:26:59.4089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT049 Archived-At: Subject: Re: [Cbor] Should encoding of JSON strings as CBOR major type 2 be explicitly prohibited? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 15:27:03 -0000 WWVzIEkgaGF2ZS4gICBJJ3ZlIGFsc28gaW52aXRlZCBoaW0gdG8gcGFydGljaXBhdGUgaGVyZS4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fi b0B0emkub3JnPiANClNlbnQ6IFRodXJzZGF5LCBNYXkgMywgMjAxOCAyOjE5IEFNDQpUbzogQnVy dCBIYXJyaXMgPGJ1cnRfaGFycmlzQGhvdG1haWwuY29tPg0KQ2M6IEJyaWFuIEUgQ2FycGVudGVy IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBjYm9yQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0Nib3JdIFNob3VsZCBlbmNvZGluZyBvZiBKU09OIHN0cmluZ3MgYXMgQ0JPUiBtYWpvciB0 eXBlIDIgYmUgZXhwbGljaXRseSBwcm9oaWJpdGVkPw0KDQpIaSBCdXJ0LA0KDQp0aGFuayB5b3Ug Zm9yIHBvaW50aW5nIG91dCB0aGUgbmVlZCBmb3IgYSBjbGFyaWZpY2F0aW9uIGhlcmUuDQpIYXZl IHlvdSBoYWQgc29tZSBjb252ZXJzYXRpb24gd2l0aCB0aGUgYXV0aG9yIG9mIHRoZSAyNTYvMjUg dGFnIHNwZWM/DQoNCk9uIE1heSAyLCAyMDE4LCBhdCAxNzowNCwgQnVydCBIYXJyaXMgPGJ1cnRf aGFycmlzQGhvdG1haWwuY29tPiB3cm90ZToNCj4gDQo+ICAgIEpTT04gc3RyaW5ncyBNVVNUIGJl IHJlcHJlc2VudGVkIGFzIENCT1IgdGV4dCBzdHJpbmdzIChtYWpvciB0eXBlIDIpIGFuZCBTSE9V TEQgYmUgcmVwcmVzZW50ZWQgaW4gdGhlIHNob3J0ZXN0IGZvcm0gYWxsb3dlZC4NCg0KNC4yIGFz c3VtZXMgdGhhdCB0aGlzIGlzIGFsbCBvYnZpb3VzLCBleGNlcHQgZm9yIG51bWJlcnMuDQpNYXli ZSB3ZSBzaG91bGQgYWRkIGEgdGFibGUgcHJvdmlkaW5nIHRoZSBtYXBwaW5nIGZvciBhbGwgdHlw ZXMsIG5vdCBqdXN0IGZvciB0ZXh0IHN0cmluZ3M/DQoNClRoZSByZWNvbW1lbmRhdGlvbiBmb3Ig dGhlIHNob3J0ZXN0IGZvcm0gYWxzbyBhcHBsaWVzIHRvIHRoZSBvdGhlciB0eXBlcywgYXMgd2Vs bCwgbm8/DQoNCk5vdGUgdGhhdCB0aGUgZW50aXJldHkgb2YgU2VjdGlvbiA0IGlzIG1lYW50IHRv IGJlIG5vbi1ub3JtYXRpdmUsIHNvIHVzaW5nIFJGQyAyMTE5IGxhbmd1YWdlIHdvdWxkIGJlIGNv bmZ1c2luZy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Mon May 7 12:22:39 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D10A12783A for ; Mon, 7 May 2018 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt2vN7vDrjqM for ; Mon, 7 May 2018 12:22:36 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010106.outbound.protection.outlook.com [40.92.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E3A126FDC for ; Mon, 7 May 2018 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hCe8UPfN7wiZtE8ItrO0qBZHyEJRdIpKD2GZhqtbhRU=; b=DgTspVZkwcqri6AnvLpXmz76OqaQMicIODTgWtyuyqRiVfdffOTkND8q87OgqFhTcOv5VyCDsvXUHdx6druNDDLVYKKKMGTJjuKqE8QgeFUCdUYSTy2n2c9DxLf/XI1tMGJSLuX4U53KHcSQP4ivYll1HPEUA3LO9zjT6ByJKSXA9GwHqNtIrb3jo6Sxv3NXzIsAUnFMyEg39Ik+MTTi2uGOwZCSEeztCo1x/raUDtmoHvoTXieT8BZ95ZmXvD19fL15UJgO9woZjHISQcE3BeYotDVguGOTPTZMVGo2tmMJwFA0ifY+r6igLALzpwrLxB7ldtBBxRcB6ZD4fh+XNw== Received: from CO1NAM04FT028.eop-NAM04.prod.protection.outlook.com (10.152.90.58) by CO1NAM04HT087.eop-NAM04.prod.protection.outlook.com (10.152.91.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.16; Mon, 7 May 2018 19:22:35 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.90.51) by CO1NAM04FT028.mail.protection.outlook.com (10.152.90.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.16 via Frontend Transport; Mon, 7 May 2018 19:22:34 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0735.019; Mon, 7 May 2018 19:22:34 +0000 From: Burt Harris To: "cbor@ietf.org" Thread-Topic: Collaboration workflow Thread-Index: AdPmOA86zVDXrqn0SGKzzpG0G8cLTg== Date: Mon, 7 May 2018 19:22:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A45F077F2CAA92B14C994A7BFD9053B8AB0BD23C6DC74B0334EEACE89FB957B7; UpperCasedChecksum:E9B9871EBB4190F767C4181D474076FE839207ACC96F6213CBF76DD9035B3BA4; SizeAsReceived:6756; Count:43 x-tmn: [WSI3WbADeohJMnPeDy7HGdBlMHANBodR] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT087; 7:wdlnWJ/UpUYBzWj4/b2zZROSuLzgzcq7UPnjLjorPnVg8SnCYG2kg+VRzeamXasNBHmXaXNE5q9ZWiWultiV/5jMVj9mAEKKST1ievtyb7HEDtZ6QnAXLSm1JZoXntZgZnfu5GQ7IZpugdDlJHSdOA+V/VTJdJSbhPHYQYrRVMVmbH94EBgzNkTuNCpVJY9bcHCPs2rQvPl6Dhy/HHsHcc61ZZCm5JwYxGsHVe2OR2eNoTG6xNHOa/q14cRKeuUH x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CO1NAM04HT087; x-ms-traffictypediagnostic: CO1NAM04HT087: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM04HT087; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT087; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT087; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: h75xOShBqf0WnKBHnciw6e7iigh3g3BYMzgcn979B5cFBa8JFvEXOnQ9o1yqQ6u6bjYXw/WV8jWBxZPydB4JrXPBvzpgK+iIt/qzI05xok5c/ytgo2DSaKTg5QMcpqaUmDGuzDGg8wS1ziCRiqatW60I95ciz3KdaFnXEThnJt+HYdugCuzfjq9QJQb2z8KF Content-Type: multipart/alternative; boundary="_000_MWHPR22MB09263A3111AEDBF6EC1F6673929B0MWHPR22MB0926namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a0c32099-c7fb-45fa-3006-08d5b44fe323 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: a0c32099-c7fb-45fa-3006-08d5b44fe323 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 19:22:34.8630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT087 Archived-At: Subject: [Cbor] Collaboration workflow X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 19:22:38 -0000 --_000_MWHPR22MB09263A3111AEDBF6EC1F6673929B0MWHPR22MB0926namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm a lot more with collaboration using github work-items than over e-mail,= but it's not clear to me if that's an approach used for this WG. For one thing, work-items remain editable after first crafted, authors can = correct spelling errors, typos, etc. without disrupting the flow of discuss= ion. Should I send mail to cbor@ietf.org for each signific= ant topic? --_000_MWHPR22MB09263A3111AEDBF6EC1F6673929B0MWHPR22MB0926namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m a lot more with collaboration using github= work-items than over e-mail, but it’s not clear to me if that’= s an approach  used for this WG.

 

For one thing, work-items remain editable after firs= t crafted, authors can correct spelling errors, typos, etc. without disrupt= ing the flow of discussion.  

 

Should I send mail to cbor@ietf.org for each significant topic?

--_000_MWHPR22MB09263A3111AEDBF6EC1F6673929B0MWHPR22MB0926namp_-- From nobody Thu May 10 11:45:32 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18FB12EB85 for ; Thu, 10 May 2018 11:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3MJZKRgfnDhz for ; Thu, 10 May 2018 11:45:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEB712EBDA for ; Thu, 10 May 2018 11:45:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E90CC20090 for ; Thu, 10 May 2018 14:57:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B56B32E37; Thu, 10 May 2018 14:45:02 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B19C82E05 for ; Thu, 10 May 2018 14:45:02 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 18:45:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm about to write an IANA Considerations section for a document that says essentially: *) that the 1-byte positive and negative integers may be allocated by IETF Standards action. *) that the 2-byte, 3-byte and 4-byte positive integers may be allocated = by IANA First Come First Served (https://tools.ietf.org/html/rfc8126#section-4.= 4) *) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as an experimental range. The exact details of the could be adjusted slightly. It seems that this ki= nd of pattern will be frequently repeated, and so I wonder if a document should be written that updates RFC8126 to create some "macro" statement about CBOR key values taht would say something like that. (Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved = is a bike shed, and every single group will re-argue this, and trying to write one or two things down is a waste of time) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvSTLoCLcPvd0N1lAQIgHAf/Ro5vy5Dr9xUkVsnjzdnGglr9inNgV16n N7PTdruwiNxXECD1TE/LPx9TnzYpoFOfpGFM5QpJ0ks1xlzFoO5bTGaqCdMX8hru EWr9S8zL1zQlJ+XoGayf/hk4kuLjqSXDv4+q1BkKxu3fo0/sYlyRQtAiSxydBK22 NhghgcVRaCN0Xpmysga/vMt/z8JbdD4PyBRMoG8Q6mBzqPJufLr7HVP/VFYVAyfj ReLJnt1lHKfN8ReYoEgzQhp/ZaZqP5VkRg69QqiQbDD03buBUJE1knPKZTQKxKq2 Lm7Aig9Z039y8rPZXqxTRq/v9fMb0w0vEgCO0wqX/5Ojq6bPOGVKPA== =Klwq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 10 13:47:23 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DE12DA26 for ; Thu, 10 May 2018 13:47:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEzPhmSgCliz for ; Thu, 10 May 2018 13:47:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A56312D779 for ; Thu, 10 May 2018 13:47:19 -0700 (PDT) Received: from Jude (192.168.1.166) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 10 May 2018 13:44:38 -0700 From: Jim Schaad To: 'Michael Richardson' , References: <13362.1525977902@localhost> In-Reply-To: <13362.1525977902@localhost> Date: Thu, 10 May 2018 13:47:07 -0700 Message-ID: <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFk3Xi6NxNP4VpjKemnMBAaz53Q6aUHhI6Q Content-Language: en-us X-Originating-IP: [192.168.1.166] Archived-At: Subject: Re: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 20:47:22 -0000 > -----Original Message----- > From: CBOR On Behalf Of Michael Richardson > Sent: Thursday, May 10, 2018 11:45 AM > To: cbor@ietf.org > Subject: [Cbor] cbor key allocations and IANA > > > I'm about to write an IANA Considerations section for a document that says > essentially: > > *) that the 1-byte positive and negative integers may be allocated by IETF > Standards action. > *) that the 2-byte, 3-byte and 4-byte positive integers may be allocated by > IANA > First Come First Served (https://tools.ietf.org/html/rfc8126#section-4.4) > *) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as > an experimental range. The first bike shed is what you mean by 1-byte and 2-byte. Are you talking about the integer value or the encoded CBOR integer value. > > The exact details of the could be adjusted slightly. It seems that this kind of > pattern will be frequently repeated, and so I wonder if a document should > be written that updates RFC8126 to create some "macro" statement about > CBOR key values taht would say something like that. I guess one question is could this be done for IANA by reference. "Use the same assignment policy as this registry" which might make things easier. I know that both of the cases where I have been involved there has ended up being some terminology discussions about what is really meant. Pointing to a extant registry and say use that policy might be easier. Jim > > (Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved > is a bike shed, and every single group will re-argue this, and trying to write > one or two things down is a waste of time) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > From nobody Thu May 10 13:47:49 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F212E03A for ; Thu, 10 May 2018 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rcocQ2A9aZmV for ; Thu, 10 May 2018 13:47:45 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0103.outbound.protection.outlook.com [104.47.33.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604BA12DA26 for ; Thu, 10 May 2018 13:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0A/VHr31aHFLpzGdzs3Ayt+EU4LljJQN7X4BcR1L1YU=; b=IYf39HzD6V0QfIfTg1YbECK1E9DjQkz7slmPvThH2EctTCmjFuhtaipueRNUSebC/51PVIpJCg5khpVgCwigrQmUmHJ0Apj2nT7oEM1+5pLs5tyH4/B+ncKYr5+g1vIcN9YNH2bByOuaHGPs+MEKeVo9u1FFB9fA8hHfR/FnA9Q= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (2603:10b6:207:1e::30) by BL0PR00MB0322.namprd00.prod.outlook.com (2603:10b6:207:1f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.795.0; Thu, 10 May 2018 20:47:33 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::84a0:cb3c:39ec:1b01%5]) with mapi id 15.20.0796.000; Thu, 10 May 2018 20:47:33 +0000 From: Mike Jones To: Michael Richardson , "cbor@ietf.org" Thread-Topic: [Cbor] cbor key allocations and IANA Thread-Index: AQHT6I8VJwofuC752UKuCSEJAf01TaQpbL/A Date: Thu, 10 May 2018 20:47:33 +0000 Message-ID: References: <13362.1525977902@localhost> In-Reply-To: <13362.1525977902@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T20:47:31.7213860Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:a::145] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0322; 7:ce8wOZWVfzPpY84oAsVFHpUu7jtTSGu5wjjvWrNxfgZbpRx/2Joiuu25QIgQww+TvgJg6lZxMXeGEtn9ZWIUOizAakl9CHuIy+qpyepEd7gbBuPbXPf8wZop/qcjpFV6bOcUfUr/rF+DyAjSTSOhJSmHj665SoYDCe0SKup0E2KJNI8fceT4Qqa2Jl/fgEbP37WovPeDSKgrYjeT4liOWubHOtfbn75D92k2x4ipD1Y7GBf0ejCydM7FI9wE14rV; 20:ce1np2E6ZWcxbD3ynCv6jwX2sSq9xeMTxJPcCc42SK8CTOOqqSW9IZ+cKh50SIwsHN7sIvZJxllxNd3i66xV5T/O6TPWnV0eurIrnMYrhFDb+4KhRcghA6kIsTVfcKXTUWif14DCj3r5C0JFdqeQAhUTQ3J0tr9zMU7jbSDAyqM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0322; x-ms-traffictypediagnostic: BL0PR00MB0322: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:BL0PR00MB0322; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0322; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(39380400002)(346002)(376002)(396003)(199004)(189003)(54094003)(13464003)(76176011)(105586002)(186003)(2900100001)(102836004)(3660700001)(2906002)(3280700002)(106356001)(110136005)(446003)(8676002)(81156014)(81166006)(46003)(33656002)(10090500001)(8936002)(486006)(22452003)(11346002)(8990500004)(476003)(305945005)(7736002)(316002)(74316002)(6506007)(53546011)(229853002)(68736007)(97736004)(14454004)(72206003)(966005)(478600001)(6246003)(2501003)(25786009)(5250100002)(99286004)(55016002)(6436002)(53936002)(9686003)(6306002)(86362001)(86612001)(52396003)(6116002)(5660300001)(10290500003)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0322; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nQnBwS0CMV6bdFymyDu4q3n1K69nZHahjVJBJyqGZOZg3xt2CLkT5ye7ZXxm3BZXlSw+jIzQPE0IlRsJyoZ4WtUBe3jPaXFD5xzF/vXLqenoPBROjpUi6bh8QCC4OrIm5j/AAvGz7Ux82NjnNGqo/m9DVlYXhPx3FNBj3I7f8fXcFCNKGvY1SSY6yxReFv/D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c2231dea-5264-4e68-38aa-08d5b6b7415d X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2231dea-5264-4e68-38aa-08d5b6b7415d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 20:47:33.3531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0322 Archived-At: Subject: Re: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 20:47:48 -0000 The shiny new CBOR Web Token (CWT) RFC - RFC uses similar language and rule= s, which were heavily discussed and vetted both by the IESG and IANA. I su= ggest that you copy them verbatim. In particular, the "Claim Key" allocation rules at https://tools.ietf.org/h= tml/rfc8392#section-9.1.1 are: Claim Key: CBOR map key for the claim. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 and strings of length 1 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 along with strings of length 2 are designated as Specification Required. Integer values greater than 65535 and strings of length greater than 2 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. These are also based on and similar the allocation rules in COSE, such as t= hose in https://tools.ietf.org/html/rfc8152#section-16.2 for labels and in = https://tools.ietf.org/html/rfc8152#section-16.8 for values. However, I wo= uld use the CWT language over the COSE language, as the IESG and IANA sugge= sted several changes to the (already clear) language in COSE. Best wishes, -- Mike -----Original Message----- From: CBOR On Behalf Of Michael Richardson Sent: Thursday, May 10, 2018 11:45 AM To: cbor@ietf.org Subject: [Cbor] cbor key allocations and IANA I'm about to write an IANA Considerations section for a document that says essentially: *) that the 1-byte positive and negative integers may be allocated by IET= F Standards action. *) that the 2-byte, 3-byte and 4-byte positive integers may be allocated = by IANA First Come First Served (https://tools.ietf.org/html/rfc8126#section-4.= 4) *) that the 2-byte, 3-byte and 4-byte negative integers be reserved for a= s an experimental range. The exact details of the could be adjusted slightly. It seems that this ki= nd of pattern will be frequently repeated, and so I wonder if a document sh= ould be written that updates RFC8126 to create some "macro" statement about= CBOR key values taht would say something like that. (Or maybe, the decision about 1-byte reserved, or 1-byte + 2-byte reserved = is a bike shed, and every single group will re-argue this, and trying to wr= ite one or two things down is a waste of time) --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Thu May 10 14:12:59 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80CE127863 for ; Thu, 10 May 2018 14:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 orZ87xZHdhGE for ; Thu, 10 May 2018 14:12:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E79412D77E for ; Thu, 10 May 2018 14:12:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BA47220090 for ; Thu, 10 May 2018 17:24:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2035B2E37; Thu, 10 May 2018 17:12:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DBF12E05 for ; Thu, 10 May 2018 17:12:35 -0400 (EDT) From: Michael Richardson To: cbor@ietf.org In-Reply-To: <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com> References: <13362.1525977902@localhost> <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:12:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: >> I'm about to write an IANA Considerations section for a document tha= t says >> essentially: >>=20 >> *) that the 1-byte positive and negative integers may be allocated by > IETF >> Standards action. >> *) that the 2-byte, 3-byte and 4-byte positive integers may be alloc= ated > by >> IANA >> First Come First Served > (https://tools.ietf.org/html/rfc8126#section-4.4) >> *) that the 2-byte, 3-byte and 4-byte negative integers be reserved = for > as >> an experimental range. > The first bike shed is what you mean by 1-byte and 2-byte. Are you t= alking > about the integer value or the encoded CBOR integer value. okay, this is a good reason why I'd like to have standardized text :-) I mean, integers that when encoded, fit into 1 byte. So, -31 to +31. >> The exact details of the could be adjusted slightly. It seems that = this >> kind of >> pattern will be frequently repeated, and so I wonder if a document s= hould >> be written that updates RFC8126 to create some "macro" statement abo= ut >> CBOR key values taht would say something like that. > I guess one question is could this be done for IANA by reference. "U= se the > same assignment policy as this registry" which might make things > easier. I Yes, we could use that way, except if that registry changed in some way. Mike Jones wrote: > The shiny new CBOR Web Token (CWT) RFC - RFC uses similar language and > rules, which were heavily discussed and vetted both by the IESG and > IANA. I suggest that you copy them verbatim. Yes, so this could for the above suggestion by Jim be the registry to point to. Do I really want to make IANA think so much? I'd rather just give it a name. > In particular, the "Claim Key" allocation rules at https://tools.ietf= .org/html/rfc8392#section-9.1.1 are: > Claim Key: > CBOR map key for the claim. Different ranges of values use > different registration policies [RFC8126]. Integer values from > -256 to 255 and strings of length 1 are designated as Standards > Action. Integer values from -65536 to -257 and from 256 to 65535 > along with strings of length 2 are designated as Specification > Required. Integer values greater than 65535 and strings of length > greater than 2 are designated as Expert Review. Integer values > less than -65536 are marked as Private Use. So I guess there is no special category from -31 to +31. Probably that's okay as we allocate those first and we are careful about them. I will do what you suggest and use your text for now. Do you think I should say, "like the Claim Key"? I think it's sufficiently well written that I'd still like to have an IANA "macro" that indicates this. > These are also based on and similar the allocation rules in COSE, such > as those in https://tools.ietf.org/html/rfc8152#section-16.2 for labe= ls > and in https://tools.ietf.org/html/rfc8152#section-16.8 for values. > However, I would use the CWT language over the COSE language, as the > IESG and IANA suggested several changes to the (already clear) langua= ge > in COSE. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvS1woCLcPvd0N1lAQLsHAgAt2Ifo0mY4K+diEtExSu6t4R1fWDIq67G NQ0vZ5IahzqOY1/0bne8kQMpBXuFe+FS0dqEu1iQUQeEkYSZ/4iQ3y/es2h9ekDl QWq07aLb9EjN3RHjTjyEnl5pp7l9+ufH9c2YpUjk2puWFNTZnWZHboRV1PSF03MP VkfpIdBSwsrq6jBeBbHKExYPrd2J8zz779lgd9C8JkZFiO8fLocRwS7zA4kPhVgg YQG2TM1ixaocZohZcPqKPF+2toJvgdpYv5BKXoue/Pgysc64K+T1c0GjLdFaaKbi vKF93f+UCUAE452ew2EnlOzFmWk2+w5XhzRrtGeIl6VliHhuHZloQg== =iGAy -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 10 14:25:35 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40612E03B for ; Thu, 10 May 2018 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 P4djj-yL4CUR for ; Thu, 10 May 2018 14:25:32 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 4D25C126DEE for ; Thu, 10 May 2018 14:25:32 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2018 14:25:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,386,1520924400"; d="scan'208";a="38387657" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga007.fm.intel.com with ESMTP; 10 May 2018 14:25:32 -0700 Received: from tjmaciei-mobl1.localnet (10.7.197.173) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 May 2018 14:25:31 -0700 From: Thiago Macieira To: CC: Michael Richardson Date: Thu, 10 May 2018 14:25:31 -0700 Message-ID: <11349835.JhF05BWlkr@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: <29933.1525986755@localhost> References: <13362.1525977902@localhost> <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com> <29933.1525986755@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.7.197.173] Archived-At: Subject: Re: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:25:33 -0000 On Thursday, 10 May 2018 14:12:35 PDT Michael Richardson wrote: > > The first bike shed is what you mean by 1-byte and 2-byte. Are you > > talking > > about the integer value or the encoded CBOR integer value. > > okay, this is a good reason why I'd like to have standardized text > I mean, integers that when encoded, fit into 1 byte. So, -31 to +31. Which is why you shouldn't write that, because it's -24 to +23. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Fri May 11 07:59:53 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45265124E15 for ; Fri, 11 May 2018 07:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5F49wR8xSL65 for ; Fri, 11 May 2018 07:59:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A411200C1 for ; Fri, 11 May 2018 07:59:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 062C420090; Fri, 11 May 2018 11:11:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4777613F1; Fri, 11 May 2018 10:59:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 44FD0131B; Fri, 11 May 2018 10:59:29 -0400 (EDT) From: Michael Richardson To: Thiago Macieira cc: cbor@ietf.org In-Reply-To: <11349835.JhF05BWlkr@tjmaciei-mobl1> References: <13362.1525977902@localhost> <00f001d3e8a0$115c4f30$3414ed90$@augustcellars.com> <29933.1525986755@localhost> <11349835.JhF05BWlkr@tjmaciei-mobl1> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] cbor key allocations and IANA X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 14:59:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thiago Macieira wrote: >> > The first bike shed is what you mean by 1-byte and 2-byte. Are you >> > talking >> > about the integer value or the encoded CBOR integer value. >>=20 >> okay, this is a good reason why I'd like to have standardized text=20 >> I mean, integers that when encoded, fit into 1 byte. So, -31 to +31. > Which is why you shouldn't write that, because it's -24 to +23. See, it's good to have a well-reviewed set of text to point to :-) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvWv0YCLcPvd0N1lAQKGcwgAl/F2N/cxA8VCnqJfdyeAwF1yhR9sN3Vd f7bzk6gxwTS+7ReAv7wvtpyZR7G8cTD4Q2YE6ek8YEOkBJ5PVUpaRxtW1sQwbxfE HkEYxnMyM+RbA9LSuRrAdgBcrejXgloX6/shbH5H1PYGgMsF6y4t/PpxrwXHumzw 58dNn/fFm54thCYbZiYMZlYxpjMNekQeXEk3qyBpP8CVjyl3hSDmgfQzAIRmwdC/ I/lnp0Y0WGW6xZCH1eCx2Ag2dm3ygmvKsBpb7oTdccnKM6ae6jjn1D4t8p5ZlmK8 1thftZPeNiE2HwWNPyE4jWnokrQuC+D2ZrCCEr3b7pGZhEAujZ7EGQ== =mIV4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 17 06:28:37 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AB12E874 for ; Thu, 17 May 2018 06:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ERkTlZgz; dkim=pass (1024-bit key) header.d=ericsson.com header.b=En7m/ZMU 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 FDTvT1FbPlaV for ; Thu, 17 May 2018 06:28:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDA5120713 for ; Thu, 17 May 2018 06:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526563711; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ss0pykgpn7z3yE3taLdA354MtABOkrgKNzTjsM9kRfo=; b=ERkTlZgz6s2Uxz8Wv6ja9qtD49y0J+54rUzz86o3BAN9z1OfLC+Qmi1wq2RWvJKM 6ySrwHAKuFBoeKA+Lpz+PdkTlhZGb4atWpOKQUoJu4iscFmNvQnr5dJPrPKUdBFB MeGHb6MyFuoqUEycPJ4h6E4xfSiw1ZGNtfDjbFmvxqg=; X-AuditID: c1b4fb30-e77ff7000000169b-2b-5afd837fc1db Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.6C.05787.F738DFA5; Thu, 17 May 2018 15:28:31 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC019.ericsson.se (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 17 May 2018 15:27:25 +0200 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 17 May 2018 15:27:24 +0200 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 17 May 2018 15:27:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQoqsGl5H1ByqYeZ4k7Ehey7k2sZq4wwQ5R/btORZag=; b=En7m/ZMUX5N/yfDhX2FHbieR80J7d2h1Z9O9Idi0L1gGlvMrv3839gTAaMxgn2/YoH0yvwhLKKDYr3oqnSRLg0vUO3CfYMIf7dpwS38ZKWmprr42kYHjXgwJm80ijVzTOiYotePRe8oPH4XFDIvtQ0JV1gcxb0jdpVZkXj8W/Fw= Received: from DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) by DB4PR07MB393.eurprd07.prod.outlook.com (10.141.236.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.4; Thu, 17 May 2018 13:27:23 +0000 Received: from DB4PR07MB347.eurprd07.prod.outlook.com ([fe80::a812:cc37:ba5d:e98c]) by DB4PR07MB347.eurprd07.prod.outlook.com ([fe80::a812:cc37:ba5d:e98c%5]) with mapi id 15.20.0776.008; Thu, 17 May 2018 13:27:23 +0000 From: Francesca Palombini To: Burt Harris , "cbor@ietf.org" Thread-Topic: [Cbor] Collaboration workflow Thread-Index: AdPmOA86zVDXrqn0SGKzzpG0G8cLTgHqqPxg Date: Thu, 17 May 2018 13:27:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB393; 7:RO20h7hFGy3eHtE7sAEfgCYcA2WwO9WcMo+2e1p8lz7kOuSEilwkAEDA51LhzWHreNDhIMahA5q61UVOU9gTEmDGHi/mvTV37OzQOk/6SSl7N+E/RhrLjqYFVTWBYS68mpFqPYvj3TBAkqDzVVesO5sfKTQ1kMz3fGP4JvRmDb1z13Qed0zTH9/MeFGJXfBQshEWh23TjJySm07QkJfiTnKk5zTOmcE9ibGxUQzzicRnJcwLZTUw1ptV++WRQCQw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB4PR07MB393; x-ms-traffictypediagnostic: DB4PR07MB393: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(271806183753584)(21748063052155)(231250463719595); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DB4PR07MB393; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB393; x-forefront-prvs: 067553F396 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(346002)(376002)(396003)(39860400002)(199004)(189003)(790700001)(25786009)(6116002)(97736004)(7736002)(99286004)(316002)(3280700002)(53546011)(3660700001)(54896002)(6306002)(7696005)(3846002)(9686003)(55016002)(478600001)(66066001)(2906002)(102836004)(74316002)(6506007)(26005)(59450400001)(6436002)(236005)(86362001)(229853002)(186003)(14454004)(8936002)(105586002)(81156014)(5250100002)(446003)(2900100001)(11346002)(966005)(8676002)(110136005)(606006)(53936002)(5660300001)(81166006)(2501003)(33656002)(6246003)(486006)(76176011)(476003)(44832011)(9326002)(39060400002)(561944003)(68736007)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB393; H:DB4PR07MB347.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tmsiQS762pmzElwb05oySEEZWqAPKoHYklxalUvAKWRN2sT6P9O5Dtw/4qyJOYEPYEHgbPnBCZi4MYLd01h2QyO7zXSMRJpc6CmnIAYmf7Js4CH2xkpbhK+f7LpxLBGtMeFrRPqlMdA9EYUKg3NsW61cyhRJeP8Y6h0vBCIK6prnTDBZgeTRRzbJEFUSyKGZ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB34711447D342B0CB537883298910DB4PR07MB347eurprd_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 3ec7d9c8-0999-46fe-56fb-08d5bbf9ece7 X-MS-Exchange-CrossTenant-Network-Message-Id: 3ec7d9c8-0999-46fe-56fb-08d5bbf9ece7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2018 13:27:23.6926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB393 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0hUURSG2+ecOR6tod2kufJWjlje06mHoSSSgsRIfIliKGzSg455mc4Z JQvTjGS0FB80MyQVR8vLWHlBLQkdijAlLyiBGmgO1KSUeYlMRptxK/j2/f/611p7bzZHy55J 3DhNqo4XUtXJctaJKb/UcS44+55VFTppPKzs661lleX6MuYUFTnzcICNNBhWqBhK5RQezydr MnjhyMmrTon5A2VIWx9x8+39MZSDLMoC5MgBPgYfK9YZO8vwOwRLP9ILkJON2xA0DI5TRPxB oB+tp4kwUDDx/BFrFwwupmG6Jl9C+ospeP83hqSmEOR8qafsBRaHw9D0r42QM46Cf70rrJ33 4gAYyX/MED8Q2gtHNzMK+Pz61UaGwb4wb6y1McdJsQpK8gPJrsuw2ry+Md4RX4GnTZ824gh7 wtLdRtrONHaFcXMlRe6JwdA9SBN2AcvMmsQ+EvBBMFj3E9sTRiofIMKtFEzOioSDYb60dLO1 HcFQXQphfxjMq6HJ2jgYnShyIL4GzAtNm/ks0LdUs4S9oKFwmrE/D+BuGnIr9VQxCn2y7aiE 02BtqpCxsxTvgb5yM0P8IKh6s8ASDoS66ll6iwd6ZqjtfhVyaEAuIi9eS0lQKEJ4QRMnimmp Iam8rgXZvk9v22poJ7J8izAhzCH5LulkolUlk6gzxMwUEwKOljtLozNtljRenXmLF9JihfRk XjQhd46Ru0qV0a0qGU5Q6/jrPK/lha0qxTm65SDJnPvcC4Vbz08f/6AdLeaK7k7fYUOVKb7/ 6NOuKA3TkTcVeVYp13s0fF+841PkN+xe6zbbddwEHkljBcs9ZWElBYe8dMa59jNjWqvRdTEy CWUtVkxc+BB/WrV68bfgHbvie+PA15fBJ/q1frf9LLnnvbN374vW4aSdjc2xUbJlOSMmqsMC aEFU/weClRl+OgMAAA== Archived-At: Subject: Re: [Cbor] Collaboration workflow X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:28:36 -0000 --_000_DB4PR07MB34711447D342B0CB537883298910DB4PR07MB347eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Burt, The approach we aim at using in this WG is: * For editorials/nits, feel free to just open issues/PR in the relative= github (no need to send to the mailing list) https://github.com/cbor-wg * For other changes, please make sure to also send them to this mailing= list. Not everybody is tracking the github issues/PR. If you have a propos= al for a change, making a PR about it and forwarding it here would simplify= the discussion in the mailing list, but is in no way required. My personal= suggestion is one mail thread per change/question/proposal, to make it eas= ier to track. Thanks, Francesca From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Burt Harris Sent: den 7 maj 2018 21:23 To: cbor@ietf.org Subject: [Cbor] Collaboration workflow I'm a lot more with collaboration using github work-items than over e-mail,= but it's not clear to me if that's an approach used for this WG. For one thing, work-items remain editable after first crafted, authors can = correct spelling errors, typos, etc. without disrupting the flow of discuss= ion. Should I send mail to cbor@ietf.org for each signific= ant topic? --_000_DB4PR07MB34711447D342B0CB537883298910DB4PR07MB347eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Burt,

 

The approach we aim at using in this WG is:

  • For editorials/nits, feel free to just open issues/PR in the relative= github (no need to send to the mailing list) https://github.com/cbor-wg =
  • For ot= her changes, please make sure to also send them to this mailing list. Not e= verybody is tracking the github issues/PR. If you have a proposal for a cha= nge, making a PR about it and forwarding it here would simplify the discussion in the mailing list, but is in no way requir= ed. My personal suggestion is one mail thread per change/question/proposal,= to make it easier to track.

 

Thanks,

Francesca

 

 

From: CBOR [mailto:cbor-bounces@ietf.org] = On Behalf Of Burt Harris
Sent: den 7 maj 2018 21:23
To: cbor@ietf.org
Subject: [Cbor] Collaboration workflow

 

I’m a lot more with collaboration using github= work-items than over e-mail, but it’s not clear to me if that’= s an approach  used for this WG.

 

For one thing, work-items remain editable after firs= t crafted, authors can correct spelling errors, typos, etc. without disrupt= ing the flow of discussion.  

 

Should I send mail to cbor@ietf.org for each significant topic?

--_000_DB4PR07MB34711447D342B0CB537883298910DB4PR07MB347eurprd_-- From nobody Fri May 18 17:13:58 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6574A1205D3 for ; Fri, 18 May 2018 17:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9bZ7rVlvDeD for ; Fri, 18 May 2018 17:13:53 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003031.outbound.protection.outlook.com [40.92.3.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F46A120721 for ; Fri, 18 May 2018 17:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yxoX+eMdceAF/RwxGO7CNQVrnbBtyQIFeAYm4B9T0S4=; b=mAaCSDoCdBs0WNXahYN3TPvfhWjYTCfjdSH4aKJl3XBTPSfxhjAqrvgbr3+e0GCnlzZiYCGi6NyBZzcgtJo8fDlhu2wHlM8Nm721PVfbMCcHNOxdZPWmUb2VBzMj6OhI9EwFUUlfleZ32Pf7w4KWo5Ho7iFJl5sRJfoaB42tPwF6ctK5T0TrL3TO+4z6SA6BkEqXw7h9IZnFuiSzbfSw10OXIWWPPdxBmaNOjjWJTs0AqT/RcKv5gjJ3luYc21pgctxe8AlikE2OoZCZn0BBmJqmz0yhjfL+Bw6XWxoKe4kBXfUFyItwNB2Dt55R1fuWjDLZxBzpyFmdNoFLKjxE5Q== Received: from BL2NAM02FT022.eop-nam02.prod.protection.outlook.com (10.152.76.55) by BL2NAM02HT076.eop-nam02.prod.protection.outlook.com (10.152.76.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.755.15; Sat, 19 May 2018 00:13:50 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.76.60) by BL2NAM02FT022.mail.protection.outlook.com (10.152.77.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.776.10 via Frontend Transport; Sat, 19 May 2018 00:13:50 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0776.010; Sat, 19 May 2018 00:13:50 +0000 From: Burt Harris To: "cbor@ietf.org" Thread-Topic: =?Windows-1252?Q?CBOR-BIS_Terminology_Refinement_:_Maps_vs_Objects, _etc?= =?Windows-1252?Q?=85?= Thread-Index: AdPuFZdcQVsWEZT/SI+vgllJm1ACAgA8J2YQ Date: Sat, 19 May 2018 00:13:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:52B3473D07EB95516907AEDFBB0170B2E8F3225D6357DBAB55A71B0070A8F683; UpperCasedChecksum:550EABF255A1B3EA96008D3CEE33ED606AEEDC9836257D36A06A77FBE7CE456B; SizeAsReceived:7115; Count:45 x-tmn: [7DIQFCnVmlRN5hqfeDHPWa9QW8aIHuLS] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2NAM02HT076; 7:nVSChVaLELW776Isep0+W5Fa3mdt+IPp0L3UAfOANG8prtuhaxNQNwf5v3GixNf01naNlV2E9d4sarasZ7jRMV3hL7PjTu1/ZAt8tv83M9/CqfrGNrBsY9RCIx7DbN4NIpcCtW1jJLtk4iKVgyfMeoZhn00YQIfER/cdbNz01fP7meXs95JEeZi5zFyI2UDVpmit44aHBcaM7AuQPWG56Qc0aO5kngSkF/c8EWtRndV3eeKqWCTHxQv3sqQourm+ x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125466)(1603101448)(1701031045); SRVR:BL2NAM02HT076; x-ms-traffictypediagnostic: BL2NAM02HT076: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BL2NAM02HT076; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT076; x-forefront-prvs: 0677FFABBF x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(606006)(7696005)(33656002)(2351001)(5660300001)(99286004)(105586002)(966005)(14454004)(20460500001)(6916009)(8936002)(82202002)(486006)(446003)(476003)(229853002)(11346002)(2473003)(5640700003)(55016002)(81156014)(9686003)(6306002)(54896002)(1730700003)(2900100001)(236005)(25786009)(2501003)(106356001)(6436002)(97736004)(104016004)(5250100002)(73972006)(6346003)(26005)(83332001)(87572001)(3280700002)(68736007)(102836004)(86362001)(74316002)(6506007)(76176011)(790700001)(3660700001)(59450400001)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT076; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: hV3mb8ksvJifaLWQ/QQoDzW8aN63puV6ywH5EJVGMmTqWOxBVaOejcrS1KhJ5A8Yzv/H+DCFHuPxe3k/h965s4YQMsQ0G6fa0GyiHdROg9okcQouKa8TxtHJZnaKwsXh1fNwAwjKsFVi3/Fg7XxhEfetmn3mO7+URKcRRELivHRMt0sMXPM+FIA/0nDzI0xb Content-Type: multipart/alternative; boundary="_000_MWHPR22MB09267D7F66F0A7BB33107CC092970MWHPR22MB0926namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6869c758-b3aa-4235-5204-08d5bd1d65e7 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 6869c758-b3aa-4235-5204-08d5bd1d65e7 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2018 00:13:50.3371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT076 Archived-At: Subject: [Cbor] =?windows-1252?q?FW=3A_CBOR-BIS_Terminology_Refinement_=3A?= =?windows-1252?q?_Maps_vs_Objects=2C__etc=85?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 00:13:57 -0000 --_000_MWHPR22MB09267D7F66F0A7BB33107CC092970MWHPR22MB0926namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve opened this as an issue at https://github.com/cbor-wg/CBORbis/issues= /25, but following Francesca=92s advice, forward the topic to the ML as wel= l=85 Terminology Refinement: Maps, Objects, etc=85 To enhance clarity and extensibility in CBORbis, it might be beneficial to = adjust some of the terminology and definitions used. For example, instead of the current draft's: Major type 5: a map of pairs of data items. Maps are also called tables, di= ctionaries, hashes, or objects (in JSON)... let's consider saying something less loaded, like: Major type 5/PAIRS - an ordered sequence of zero or more key-value pairs... This illustrates a number of shifts in wording and intent which I propose: * It's simpler and less restrictive. For example, it does not prevent m= ultimaps from being represented with a properly tagged 5/PAIRS data item. M= ultimaps can be quite useful (HTTP and CoAP protocol headers are multimaps)= , but it is reasonable to limit them as a tagged extension to CBOR (see bel= ow.) * Terms like maps, tables, dictionaries, hashes and objects are .abstra= ct concepts that further restrict allowed content of the 5/PAIRS major type= , they are not synonyms for it. The details of how those abstract types beh= ave is subject to some ambiguity, so it's better not to use them in definin= g the major type. CBOR tags can be used to identify which abstract type is = intended. * CBOR major types should be visually distinct from the abstract types = because major type alone does not determine the abstract type of an item; t= ags can modify the abstract type. Consistently using both the major type nu= meric value and an associated name (in caps) would help make the difference= clear. * Saying 5/PAIRS is ordered simply reflects reality, in a CBOR byte str= eam they must be in some order, because it is a serialization format. Elimi= nating the key uniqueness requirement from the major type allows encoding m= ore types, e.g. multi-maps. However, it would still be desirable to define how an untagged 5/PAIRS acts= behave with greater specificity. For example, to address the issue of key = equivalence and canonicalization, it could be very useful for an UNTAGGED 5= /PAIRS to adopt the ECMAScript/JSON object restrictions that keys be limite= d to unique numbers and text strings. Highly constrained environments may h= ave trouble supporting anything more general, but that should not restrict = the content of a tagged 5/PAIRS collection, which might allow for the use o= f a Map tag that could imply full flexibility of encoding non-string/number= keys, while a Map tagged object might obey different key-equivalence and c= anonicalization rules, with greater overhead, for example the byte wise lex= icographic order now proposed. ECMAScript object Canonicalization Order Modern ECMAScript objects are defined with some little-known behavior that = could really help bring to some of the thorny canonicalization issues. ECMA= Script objects are not hashes, their properties are ordered. But the order = can surprise some people, the keys (in order) are: 1. Non-negative numbers keys in ascending order; followed by 2. Strings keys (including negative numbers) in the order they were adde= d to the object; 3. ECMAScript Symbols (which themselves would have to be tagged in COBAR= ) By adopting the above rule as a SHOULD for canonical objects (UNTAGGED 5/PA= IRS), we gain several advantages: * In CBOR based standards for constrained environments [e.g. CBOR Objec= t Signing and Encryption (COSE)], standardized non-negative integer keys so= rt first. A highly constrained implementation of COSE might choose to inter= pret only the non-negative integer keys in ascending order and skip out whe= n other key types are detected. * Uniqueness constraints and canonical order of keys made up of other t= ypes becomes an application-level concern. However, applications that handl= e existing data in a some existing canonical order, should be automatic bec= ause the order is preserved. Most if not all dynamic languages use the ordered map for object properties= (rather than unordered) because it can lead to much better performance usi= ng JIT compiler technology. Modern versions of ECMAScript has a separate Ma= p type (since ES2016) with capacity for a wider variety of keys (e.g. objec= ts and arrays can be used as keys), but interestingly it chooses to define = equality and uniqueness constraints for map types to be based on reference = equality (identity), not value equality. Mirroring ECMAScript's ordering and uniqueness constraint rules for untagge= d 5/PAIRS might impose some additional overhead in implementations in other= languages, but for the common cases (key isa string and key isa non-negati= ve-integer) it provides a fairly low overhead approach implementable in mos= t (if not all) environments. Defining the CBOR Data Model in common Web Infrastructure terminology I would also like to propose defining the CBOR data model in terms familiar= to web developers. For this purpose, the WHATWG Infrastructure Living Stan= dard includes useful set of definitons that include most of the con= cepts needed. Referencing that document informationally, and selectively co= pying some of the definitions we need into CBORbis seems appropriate with r= egard to clarity and intellectual property. For example, the abstract conce= pts of the pair, tuple, and struct t= hat may be useful for both CBOR and CDDL already exist there. Furthermore m= ore frequently used terms such as string and byte sequence, and t= he definitions there have been carefully vetted regarding security concerns= , for example, excluding surrogate code points in UTF-8. --_000_MWHPR22MB09267D7F66F0A7BB33107CC092970MWHPR22MB0926namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I=92ve opened this as an issue at https://github.com/cbor-wg/CBORbis/issues/25, but following = Francesca=92s advice, forward the topic to the ML as well=85

Terminology Refinement: Maps, Object= s, etc=85

 

To enh= ance clarity and extensibility in CBORbis, it might be beneficial to adjust= some of the terminology and
definitions used. For example, instead of the current draft's:

Major = type 5: a map of pairs of data items. Maps are also called tables, dictiona= ries, hashes, or objects (in JSON)...

&= nbsp;

let's = consider saying something less loaded, like:

Major = type 5/PAIRS - an ordered sequence of zero or more key-value pairs...

&= nbsp;

This i= llustrates a number of shifts in wording and intent which I propose:

  • It's simpler and les= s restrictive. For example, it does not prevent multimaps from being repres= ented with a properly tagged 5/PAIRS data item. Multimaps can be quite usef= ul (HTTP and CoAP protocol headers are multimaps), but it is reasonable to limit them as a tagged extension to CB= OR (see below.)
  • Terms like maps, tab= les, dictionaries, hashes and objects are .abstract concepts that further r= estrict allowed content of the 5/PAIRS major type, they are not synonyms fo= r it. The details of how those abstract types behave is subject to some ambiguity, so it's better not to use them = in defining the major type. CBOR tags can be used to identify which abstrac= t type is intended.
  • CBOR major types sho= uld be visually distinct from the abstract types because major type alone d= oes not determine the abstract type of an item; tags can modify the abstrac= t type. Consistently using both the major type numeric value and an associated name (in caps) would help make the di= fference clear.
  • Saying 5/PAIRS is or= dered simply reflects reality, in a CBOR byte stream they must be in some order= , because it is a serialization format. Eliminating the key uniqueness requ= irement from the major type allows encoding more types, e.g. multi-maps.

Howeve= r, it would still be desirable to define how an untagged 5/PAIRS acts behav= e with greater specificity. For example, to address the issue of key equiva= lence and canonicalization, it could be very useful for an UNTAGGED<= /span> 5/PAIRS to adopt the ECMAScript/JSON object restrictions that keys be limited to unique numbers and text strings. Hig= hly constrained environments may have trouble supporting anything more gene= ral, but that should not restrict the content of a tagged 5/PAIRS collection, which might allow for the use of a= Map tag that could im= ply full flexibility of encoding non-string/number keys, while a Map tagged object might obey different key-equivalence and canonicalization rules, with = greater overhead, for example the byte wise lexicographic order now propose= d.

ECMASc= ript object Canonicalization Order

Modern= ECMAScript objects are defined with some little-known behavior that could = really help bring to some of the thorny canonicalization issues. ECMAScript= objects are not hashes, their pro= perties are ordered. But the orde= r can surprise some people, the keys (in order) are:

  1. Non-negative numbers= keys in ascending order; followed by
  2. Strings keys (includ= ing negative numbers) in the order they were added to the object;
  3. ECMAScript Symbols (= which themselves would have to be tagged in COBAR)

    4. By ado= pting the above rule as a SHOULD for canonical objects (UNTAGGED 5/PAIRS), = we gain several advantages:

    • In CBOR based standa= rds for constrained environments [e.g. CBOR Object Signing and Encryption (= COSE)], standardized non-negative integer keys sort first. A highly constra= ined implementation of COSE might choose to interpret only the non-negative integer keys in ascending order and ski= p out when other key types are detected.
    • Uniqueness constrain= ts and canonical order of keys made up of other types becomes an applicatio= n-level concern. However, applications that handle existing data in a some = existing canonical order, should be automatic because the order is preserved.

    Most i= f not all dynamic languages use the ordered map for object properties (rath= er than unordered) because it can lead to much better performance using JIT= compiler technology. Modern versions of ECMAScript has a separate Map type (since ES2016) with capacity for a w= ider variety of keys (e.g. objects and arrays can be used as keys), but int= erestingly it chooses to define equality and uniqueness constraints for map= types to be based on reference equality (identity), not value equality.

    Mirror= ing ECMAScript's ordering and uniqueness constraint rules for untagged 5/PA= IRS might impose some additional overhead in implementations in other langu= ages, but for the common cases (key isa string and key isa non-negative-integer) it provides a fairly low overhead= approach implementable in most (if not all) environments.

    Defini= ng the CBOR Data Model in common Web Infrastructure terminology<= /span>

    I woul= d also like to propose defining the CBOR data model in terms familiar to we= b developers. For this purpose, the WH= ATWG Infrastructure Living Standard includes useful set of definitons that include most of the concepts = needed. Referencing that document informationally, and selectively copying = some of the definitions we need into CBORbis seems appropriate with regard to clarity and intellectual property. For ex= ample, the abstract concepts of the pair, tuple, and struct that may be useful for both CBOR and CDDL already ex= ist there. Furthermore more frequently used terms such as string and byte sequence, and the definitions there have been c= arefully vetted regarding security concerns, for example, excluding surroga= te code points in UTF-8.

--_000_MWHPR22MB09267D7F66F0A7BB33107CC092970MWHPR22MB0926namp_-- From nobody Sat May 19 08:17:31 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6BC12D94C for ; Sat, 19 May 2018 08:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFWCBARmp2_9 for ; Sat, 19 May 2018 08:17:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241D3129C6D for ; Sat, 19 May 2018 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4JFHLRY023896; Sat, 19 May 2018 17:17:21 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40p7v52lT4zDWvR; Sat, 19 May 2018 17:17:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sat, 19 May 2018 17:17:20 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 548435838.732919-52aa63652a8504cacb0711073339a7cd Content-Transfer-Encoding: quoted-printable Message-Id: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> References: To: Burt Harris X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgIGV0Y+KApg==?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 15:17:30 -0000 Hi Burt, thank you for all your input to the CBORbis effort. I=E2=80=99m all for = cleaning up the terminology (as long as we don=E2=80=99t confuse = existing users too much). But what you are proposing here goes way = beyond terminology. Replacing maps with alists (association lists, i.e. sequences of pairs) = would have been a valid choice in 2013, when CBOR was standardized. We = thought a lot about this, and in the end staying close to JSON won out = over the additional flexibility alists provide. So in the generic data model of CBOR, we have maps. We indeed serialize = them as sequences of pairs. But CBOR is not just a syntax for = serialization, it also comes with a processing model (which is what = enables generic decoders). Here, generic decoders are free to lose the = serialization order of incoming maps and to be confused by duplicate = keys and drop some of the pairs. Changing that would be a significant change to CBOR. It is also not = really necessary, as we already have the array type for sequences. So = an alist can be represented by an array where the even numbered elements = are keys and the odd numbered ones are values. (The disadvantage is = slightly less coding efficiency as the argument is twice as much as for = maps, and the possibility to encode an odd number of elements which = can=E2=80=99t be mapped into pairs. Not really big problems in the = majority of cases.) Of course I like programming environments that provide ordered maps, = multimaps etc. CBOR provides many ways to serialize these (and maybe we = need a few more tags to be unambiguous in this space). But major type 5 = is about (unordered) maps, specifically. Gr=C3=BC=C3=9Fe, Carsten > On May 19, 2018, at 02:13, Burt Harris = wrote: >=20 > I=E2=80=99ve opened this as an issue at = https://github.com/cbor-wg/CBORbis/issues/25, but following = Francesca=E2=80=99s advice, forward the topic to the ML as well=E2=80=A6 > Terminology Refinement: Maps, Objects, etc=E2=80=A6 > =20 > To enhance clarity and extensibility in CBORbis, it might be = beneficial to adjust some of the terminology and > definitions used. For example, instead of the current draft's: >=20 > Major type 5: a map of pairs of data items. Maps are also called = tables, dictionaries, hashes, or objects (in JSON)... > =20 >=20 > let's consider saying something less loaded, like: >=20 > Major type 5/PAIRS - an ordered sequence of zero or more key-value = pairs... > =20 >=20 > This illustrates a number of shifts in wording and intent which I = propose: >=20 > =E2=80=A2 It's simpler and less restrictive. For example, it = does not prevent multimaps from being represented with a properly tagged = 5/PAIRS data item. Multimaps can be quite useful (HTTP and CoAP protocol = headers are multimaps), but it is reasonable to limit them as a tagged = extension to CBOR (see below.) > =E2=80=A2 Terms like maps, tables, dictionaries, hashes and = objects are .abstract concepts that further restrict allowed content of = the 5/PAIRS major type, they are not synonyms for it. The details of how = those abstract types behave is subject to some ambiguity, so it's better = not to use them in defining the major type. CBOR tags can be used to = identify which abstract type is intended. > =E2=80=A2 CBOR major types should be visually distinct from the = abstract types because major type alone does not determine the abstract = type of an item; tags can modify the abstract type. Consistently using = both the major type numeric value and an associated name (in caps) would = help make the difference clear. > =E2=80=A2 Saying 5/PAIRS is ordered simply reflects reality, in = a CBOR byte stream they must be in some order, because it is a = serialization format. Eliminating the key uniqueness requirement from = the major type allows encoding more types, e.g. multi-maps. > However, it would still be desirable to define how an untagged 5/PAIRS = acts behave with greater specificity. For example, to address the issue = of key equivalence and canonicalization, it could be very useful for an = UNTAGGED5/PAIRS to adopt the ECMAScript/JSON object restrictions that = keys be limited to unique numbers and text strings. Highly constrained = environments may have trouble supporting anything more general, but that = should not restrict the content of a tagged 5/PAIRS collection, which = might allow for the use of a Map tag that could imply full flexibility = of encoding non-string/number keys, while a Map tagged object might obey = different key-equivalence and canonicalization rules, with greater = overhead, for example the byte wise lexicographic order now proposed. >=20 > ECMAScript object Canonicalization Order >=20 > Modern ECMAScript objects are defined with some little-known behavior = that could really help bring to some of the thorny canonicalization = issues. ECMAScript objects are not hashes, their properties are ordered. = But the order can surprise some people, the keys (in order) are: >=20 > =E2=80=A2 Non-negative numbers keys in ascending order; followed = by > =E2=80=A2 Strings keys (including negative numbers) in the order = they were added to the object; > =E2=80=A2 ECMAScript Symbols (which themselves would have to be = tagged in COBAR) > By adopting the above rule as a SHOULD for canonical objects (UNTAGGED = 5/PAIRS), we gain several advantages: >=20 > =E2=80=A2 In CBOR based standards for constrained environments = [e.g. CBOR Object Signing and Encryption (COSE)], standardized = non-negative integer keys sort first. A highly constrained = implementation of COSE might choose to interpret only the non-negative = integer keys in ascending order and skip out when other key types are = detected. > =E2=80=A2 Uniqueness constraints and canonical order of keys = made up of other types becomes an application-level concern. However, = applications that handle existing data in a some existing canonical = order, should be automatic because the order is preserved. > Most if not all dynamic languages use the ordered map for object = properties (rather than unordered) because it can lead to much better = performance using JIT compiler technology. Modern versions of ECMAScript = has a separate Map type (since ES2016) with capacity for a wider variety = of keys (e.g. objects and arrays can be used as keys), but interestingly = it chooses to define equality and uniqueness constraints for map types = to be based on reference equality (identity), not value equality. >=20 > Mirroring ECMAScript's ordering and uniqueness constraint rules for = untagged 5/PAIRS might impose some additional overhead in = implementations in other languages, but for the common cases (key isa = string and key isa non-negative-integer) it provides a fairly low = overhead approach implementable in most (if not all) environments. >=20 > Defining the CBOR Data Model in common Web Infrastructure terminology >=20 > I would also like to propose defining the CBOR data model in terms = familiar to web developers. For this purpose, the WHATWG Infrastructure = Living Standard includes useful set of definitons that include most of = the concepts needed. Referencing that document informationally, and = selectively copying some of the definitions we need into CBORbis seems = appropriate with regard to clarity and intellectual property. For = example, the abstract concepts of the pair, tuple, and struct that may = be useful for both CBOR and CDDL already exist there. Furthermore more = frequently used terms such as string and byte sequence, and the = definitions there have been carefully vetted regarding security = concerns, for example, excluding surrogate code points in UTF-8. > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Sat May 19 08:23:08 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916212D945 for ; Sat, 19 May 2018 08:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 D75k1Gp5GBb3 for ; Sat, 19 May 2018 08:23:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26EB129C6D for ; Sat, 19 May 2018 08:23:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 937CD20093 for ; Sat, 19 May 2018 11:35:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 653093088; Sat, 19 May 2018 11:22:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 62FBB3087 for ; Sat, 19 May 2018 11:22:40 -0400 (EDT) From: Michael Richardson To: "cbor\@ietf.org" In-Reply-To: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> References: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgZXRj4oCm?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 15:23:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > So in the generic data model of CBOR, we have maps. We indeed seriali= ze > them as sequences of pairs. But CBOR is not just a syntax for > serialization, it also comes with a processing model (which is what > enables generic decoders). Here, generic decoders are free to lose t= he > serialization order of incoming maps and to be confused by duplicate > keys and drop some of the pairs. And, it's also, from what I understand, what JSON specifies, so even if we were to change this behaviour, I think we'd still want a structure that maps 1:1 with JSON maps. > Changing that would be a significant change to CBOR. It is also not > really necessary, as we already have the array type for sequences. So > an alist can be represented by an array where the even numbered > elements are keys and the odd numbered ones are values. (The > disadvantage is slightly less coding efficiency as the argument is > twice as much as for maps, and the possibility to encode an odd number > of elements which can=E2=80=99t be mapped into pairs. Not really big= problems > in the majority of cases.) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWwBBQICLcPvd0N1lAQJKQQf/fc0+hiWrY9yIlOKdY+QDgDp2FXJUG106 Jci1PAZxFj6s2ktUgNle5JaDSzdUXUbIcG4DDvf/YZpkGPDraOhF16yejxYhCj+c uVdT8qLgpko/NYNdrpfYq/tymfgweug2+mmgGyQUox3jy7ocq5gSSKKGCNhtezQU XKdwV/lJdjXfWisOHSgz10+p44SH7Jl8w68WwnWhEE1uXOiLNAkzOdkTyPRJZTtS pYWEJlfd860AfGytjF2pDO9X3f4NEk9yCuAa/1QAnR5KAUMh6YK+vAXpnrX5F6Ay 4v8hdVdLWJ7U5RZ2V6OHgNLFgnjTdYFFeEMqPfDQQ2EGVK6c3QJ1ug== =5jQy -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 21 19:49:08 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC98120047 for ; Mon, 21 May 2018 19:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHBL7zRz6KYj for ; Mon, 21 May 2018 19:49:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007070.outbound.protection.outlook.com [40.92.7.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07881201F2 for ; Mon, 21 May 2018 19:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OgHigdAGD8MUNXC1Lcy5aEovSSwNLwD+PWRvCWUfTT0=; b=aRjuijC10z3ZiQPHoxEtOJx6beTPKlWUXb2a4DfQJLF8auYwUVq064MDOf6kd8Bu7PE1oltoswLC7v3HyN6wUNGaJYTwLIq9++ZVMhBnbScfKYcMzkKdZkxCNRLvTwfyIsM7pEdCq4iXv2fD66ylGLMdED2g6eEARZ/zxBzBXtrEoMAqj2an1sSusSzEFI6b9nSSKG/1djArxJzYLU8/79M3s8Pumg62K7rzsbN271jTzv6ZPmBHYwvSuYaXxCT8s2MJr8Whkx+coYugOn2kFYmuXW4+UfczOPiYb0YO6TSzHuyJCpOYcPbkfXvGWcdJAyDUNZIV11Ymzknomqyxig== Received: from CO1NAM03FT063.eop-NAM03.prod.protection.outlook.com (10.152.80.53) by CO1NAM03HT083.eop-NAM03.prod.protection.outlook.com (10.152.81.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.755.15; Tue, 22 May 2018 02:49:02 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.80.59) by CO1NAM03FT063.mail.protection.outlook.com (10.152.81.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.776.10 via Frontend Transport; Tue, 22 May 2018 02:49:02 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0776.015; Tue, 22 May 2018 02:49:02 +0000 From: Burt Harris To: Carsten Bormann CC: "cbor@ietf.org" Thread-Topic: =?utf-8?B?W0Nib3JdIENCT1ItQklTIFRlcm1pbm9sb2d5IFJlZmluZW1lbnQgOiBNYXBz?= =?utf-8?B?IHZzIE9iamVjdHMsICBldGPigKY=?= Thread-Index: AQHT74R+9JXEWUPwSkep/VHclb8HX6Q6pJjQ Date: Tue, 22 May 2018 02:49:02 +0000 Message-ID: References: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> In-Reply-To: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:14196D1893F7A99A828B49B41DDE369172E7FE78A30CE89A19C3C6ED81C808D6; UpperCasedChecksum:DB6C1C7773F4D2606FA5242414D098261A8C3F5343E8191439B9F67E24674B4B; SizeAsReceived:7275; Count:46 x-tmn: [MZP4gXx2SL/3Ob/FuVYUqAX1PdWFeVSE] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM03HT083; 7:SkZQCepOQrPL71a2o6eYaKtL+iT5IE3qFydA7CuiMFSCdna7EyxdkmWLCx8FrOlK/8zoaaX5v9kE0ZqaPTAzkRDC7yyZQ5BbWHnvxyvH5z6L3ULqGE7qEbNiWfCkuos6hVhCa582UG14lXzOu4RHIMWYV0NbptgPAb/ZqKu9QPl6A7jRA5W9HTS4/kQvt556Pv0dfyJvjWat8N1fzS+ifDr1Z/kk3F511q8vuFycDN0XahiHrzWg5zrmImt0Qf0n x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:CO1NAM03HT083; x-ms-traffictypediagnostic: CO1NAM03HT083: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM03HT083; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT083; x-forefront-prvs: 0680FADD48 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(13464003)(189003)(199004)(11346002)(2900100001)(14454004)(486006)(8936002)(575784001)(86362001)(97736004)(81156014)(104016004)(5250100002)(82202002)(476003)(74316002)(6916009)(446003)(105586002)(106356001)(5660300001)(9686003)(6306002)(229853002)(55016002)(25786009)(73972006)(305945005)(76176011)(83332001)(6246003)(33656002)(3280700002)(59450400001)(4326008)(6346003)(53546011)(6436002)(102836004)(6506007)(7696005)(87572001)(99286004)(45080400002)(3660700001)(68736007)(966005)(345774005)(26005)(20460500001)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT083; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: DiFMDZCh0hBTpjOmbeV4vf+Z+tOZxdceer1AFkxpwtCbhQzjIHUQV4WVZFuD0jHS+tdlZ/6G4sBMU0FwGKgb8rCoLK71zg0ujX8ZtogS6doGWHxvwm1zIznX3JacTdtVwUMcuCqLAyTm41s7jsN5Apppp+osESoDEMOwChPQxUtlBUKfdUa8Llq9Sr8tblkh Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0a2c4987-e46b-4aa6-f29e-08d5bf8e9394 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 0a2c4987-e46b-4aa6-f29e-08d5bf8e9394 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2018 02:49:02.4597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT083 Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgIGV0Y+KApg==?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 02:49:07 -0000 VGhhbmtzIENhcnN0ZW4sICAgDQoNCllvdXIgcHJvYmFibHkgcmlnaHQsIGl0IG1pZ2h0IGhhdmUg YmVlbiBiZXR0ZXIgZm9yIG1lIHRvIHNlcGFyYXRlIG15IHRlcm1pbm9sb2d5IHN1Z2dlc3Rpb25z IGZyb20gdGhlIHRyaWNraWVyIGlzc3VlcyBsaWtlIGtleSB1bmlxdWVuZXNzLCBvcmRlcmluZyBh bmQgbm9ybWFsaXphdGlvbiwgYnV0IHRoZXkgX2FyZV8gaW50ZXJyZWxhdGVkIGFzIGxvbmcgYXMg d2UgdXNlIHRlcm1zIGxpa2UgIm1hcCIgIHRvIGRlc2NyaWJlIENCT1IgbWFqb3IgdHlwZXMuICAg IA0KDQpMZXQncyBiYWNrIHVwIGFuZCBzdGFydCB3aXRoIGFuIGVhc3kgdGVybWlub2xvZ3kgc3Vn Z2VzdGlvbjogICBDYW4gd2UgYXZvaWQgdGhlIHdvcmQgInN0cmluZyIgIGluIG5hbWluZyBtYWpv ciB0eXBlcyAyICYgMy4gICBUaGUgcmVhc29uIGlzIHRoYXQgZGlmZmVyZW50IHJ1bnRpbWUgZW52 aXJvbm1lbnRzIGhhdmUgZGlmZmVyZW50IGNvbmNlcHRzIG9mICJzdHJpbmciLCBlLmcuIHNvbWUg c3RvcmluZyA4LWJpdCB2YWx1ZXMsIHNvbWUgbm90OyAgc29tZSBpbW11dGFibGUsIG90aGVycyBu b3Q7ICBzb21lIGFyZSBjYXNlIHNlbnNpdGl2ZSwgYSBmZXcgbm90LiAgIFVzaW5nIHRoZSB0ZXJt ICdieXRlIHN0cmluZycganVzdCBhZGRzIGNvbmZ1c2lvbiB0byB0aGUgYWxyZWFkeSB0cmlja3kg dG9waWMgb2YgdGV4dCByZXByZXNlbnRhdGlvbi4gICBEb2VzIHVzaW5nIHNob3J0IGRpc3RpbmN0 IHRva2VucyBsaWtlIDIvVEVYVCBhbmQgMy9CWVRFUyB0byByZXByZXNlbnQgQ0JPUiAgYXBwZWFs IHRvIHlvdT8NCg0KTW9yZSBnZW5lcmFsbHksIGxldCdzIGNob29zZSBuYW1pbmcgY29udmVudGlv bnMgdGhhdCBkaXN0aW5ndWlzaCBiZXR3ZWVuICJraW5kcyIgb2YgdHlwZXM6DQoNCiAgMS4gU3lu dGF4IHR5cGVzOiBjYWxsZWQgbWFqb3IgdHlwZXMgaW4gQ0JPUi4gICANCg0KICAyLiBTZW1hbnRp YyB0eXBlcy4gICBJIHRoaW5rIHRoaXMgaXMgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgd2hl biB5b3Ugc2F5IGEgInByb2Nlc3NpbmcgbW9kZWwiLCBidXQgdG8gbWUgdGhhdCdzIHdoZXJlIGl0 IGdldHMgdHJpY2t5LiAgDQoNCiAgMy4gQWJzdHJhY3QgdHlwZXMsIHNwZWNpZmljIHRvIGEgcnVu dGltZSBlbnZpcm9ubWVudC4gIEludGVyZmFjZXMsIGdlbmVyaWNzLCBvciBhYnN0cmFjdCB0eXBl cywgZS5nLiANCgktIGBJRGljdGlvbmFyeWAsIGBJT3JkZXJlZERpY3Rpb25hcnlgLCBgSVNvcnRl ZERpY3Rpb25hcnlgICAoaW50ZXJmYWNlcyBDIyksIA0KCS0gYCBEaWN0aW9uYXJ5YCBhbmQgSGFz aE1hcCcgKGFic3RyYWN0IGNsYXNzZXMgamF2YS51dGlsKSwNCgktIGAgTWFwPEssVj5gICBhbmQg YE9iamVjdGAgKGludGVyZmFjZXMgaW4gVHlwZVNjcmlwdCkNCgktICBBYnN0cmFjdCB0eXBlcyBt YXkgbm90IGhhdmUgbXVjaCByZWxldmFuY2UgdG8gQ0JPUiwgYnV0IGFyZSBjb25jZXB0dWFsbHkg YSBsaXR0bGUgZGlmZmVyZW50IGZyb20gc2VtYW50aWMgdHlwZXMuDQoNCiAgNC4gQ29uY3JldGUg dHlwZXMgcmVhbGl6YWJsZSBpbiBhIHBhcnRpY3VsYXIgcnVudGltZSBlbnZpcm9ubWVudCBlLmcu IA0KCS0gYEhhc2h0YWJsZWAgaW4gSmF2YQ0KCS0gYE1hcGAgYW5kIGBPYmplY3RgIChjbGFzc2Vz IGluIEphdmFTY3JpcHQpDQoJLSBgc3RyaW5nYCByZWZlcnJpbmcgdG8gdGV4dCBpbiBtb3N0IGxh bmd1YWdlcw0KCS0gVGhlc2UgYXJlIGNsZWFybHkgdmVyeSByZWxldmFudCB0byBDQk9SLCBkZWNp c2lvbnMgdG8gbWFwIGZyb20gc2VtYW50aWMgdHlwZSB0byBjb25jcmV0ZSB0eXBlLg0KDQpUaGUg dGVybSAiYXNzb2NpYXRpb24gbGlzdCIgaXMgYSBncmVhdCBleGFtcGxlIG9mIHdoeSBzZXBhcmF0 aW5nIHRlcm1pbm9sb2d5IGZvciB0aGVzZSBpcyBpbXBvcnRhbnQ7IGluIGZ1bmN0aW9uYWwgbGFu Z3VhZ2VzIHJ1bnRpbWVzIGxpa2UgTElTUCwgU2NoZW1lLCBPQ2FtbCBhbmQgSGFza2VsbCwgYXNz b2NpYXRpb24gbGlzdHMgYXJlIGFuIGltbXV0YWJsZSBjb25jcmV0ZSB0eXBlIHdpdGggcnVudGlt ZSBvcGVyYXRpb25zIHF1aXRlIGRpZmZlcmVudCBmcm9tIG1hcC9kaWN0aW9uYXJ5L29iamVjdC9o YXNodGFibGUgb2YgaW1wZXJhdGl2ZSBwcm9ncmFtbWluZyBsYW5ndWFnZXMuICAgU28gZXZlbiB0 aG91Z2ggSSBrbm93IG9mIGFzc29jaWF0aW9uIGxpc3RzLCBJIHdvdWxkbid0IHdhbnQgdG8gb3Zl cmxvYWQgdGhlIHRlcm0gYXMgYSBuYW1lIGZvciBtYWpvciB0eXBlIDUuICBJJ2Qgc3VnZ2VzdCBl aWdodCBjb25zaXN0ZW50IG5vdGF0aW9ucyBsaWtlOiAwL1VJTlQsIDEvTkVHSU5ULCAyL0JZVEVT LCAzL1RFWFQsIDQvU0VRLCA1L1BBSVJTLCA2L1RBRywgNy9PVEhFUiBiZW5lZml0cyBjbGFyaXR5 IG9mIHRoZSBzcGVjIHdpdGhvdXQgY2hhbmdpbmcgYW55dGhpbmcgYWJvdXQgaG93IHRoZXNlIGNv ZGVzIGFyZSBwYXJzZWQgdW5kZXIgUkZDNzA0OS4NCg0KV2hlbiB1bnRhZ2dlZCA0L1NFUSBvYnZp b3VzbHkgaXMgdHJlYXRlZCBhcyBhbiBhcnJheSwgYnV0IHdpdGggYSBsZWFkaW5nIHRhZyBtaWdo dCByZXByZXNlbnQgc29tZXRoaW5nIGVsc2UuICAgRm9yIGV4YW1wbGUgaWYgcHJlZml4ZWQgd2l0 aCBUQUcgNCwgdGhlIG1ham9yIHR5cGUgNCBpcyBpbnRlcnByZXRlZCBhcyBhIDItdHVwbGUgcmVw cmVzZW50aW5nIGEgc2NhbGFyIHJhdGlvbmFsIG51bWJlciwgbm90IGFuIGFycmF5LCByaWdodD8g ICAgIFRoYXQgaXMgaW4gbXkgbWluZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN5bnRheCB0eXBl cyBhbmQgc2VtYW50aWMgdHlwZXMuDQoNCkknbGwgY29udGludWUgIHRoZSBvcmRlcmVkIHZzIHVu b3JkZXJlZCBtYXAgbWF0dGVyIGluIGEgc2VwYXJhdGUgdGhyZWFkLi4uDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPiAN ClNlbnQ6IFNhdHVyZGF5LCBNYXkgMTksIDIwMTggODoxNyBBTQ0KVG86IEJ1cnQgSGFycmlzIDxi dXJ0X2hhcnJpc0Bob3RtYWlsLmNvbT4NCkNjOiBjYm9yQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0Nib3JdIENCT1ItQklTIFRlcm1pbm9sb2d5IFJlZmluZW1lbnQgOiBNYXBzIHZzIE9iamVjdHMs IGV0Y+KApg0KDQpIaSBCdXJ0LA0KDQp0aGFuayB5b3UgZm9yIGFsbCB5b3VyIGlucHV0IHRvIHRo ZSBDQk9SYmlzIGVmZm9ydC4gIEnigJltIGFsbCBmb3IgY2xlYW5pbmcgdXAgdGhlIHRlcm1pbm9s b2d5IChhcyBsb25nIGFzIHdlIGRvbuKAmXQgY29uZnVzZSBleGlzdGluZyB1c2VycyB0b28gbXVj aCkuICBCdXQgd2hhdCB5b3UgYXJlIHByb3Bvc2luZyBoZXJlIGdvZXMgd2F5IGJleW9uZCB0ZXJt aW5vbG9neS4NCg0KUmVwbGFjaW5nIG1hcHMgd2l0aCBhbGlzdHMgKGFzc29jaWF0aW9uIGxpc3Rz LCBpLmUuIHNlcXVlbmNlcyBvZiBwYWlycykgd291bGQgaGF2ZSBiZWVuIGEgdmFsaWQgY2hvaWNl IGluIDIwMTMsIHdoZW4gQ0JPUiB3YXMgc3RhbmRhcmRpemVkLiAgV2UgdGhvdWdodCBhIGxvdCBh Ym91dCB0aGlzLCBhbmQgaW4gdGhlIGVuZCBzdGF5aW5nIGNsb3NlIHRvIEpTT04gd29uIG91dCBv dmVyIHRoZSBhZGRpdGlvbmFsIGZsZXhpYmlsaXR5IGFsaXN0cyBwcm92aWRlLg0KDQpTbyBpbiB0 aGUgZ2VuZXJpYyBkYXRhIG1vZGVsIG9mIENCT1IsIHdlIGhhdmUgbWFwcy4gV2UgaW5kZWVkIHNl cmlhbGl6ZSB0aGVtIGFzIHNlcXVlbmNlcyBvZiBwYWlycy4gIEJ1dCBDQk9SIGlzIG5vdCBqdXN0 IGEgc3ludGF4IGZvciBzZXJpYWxpemF0aW9uLCBpdCBhbHNvIGNvbWVzIHdpdGggYSBwcm9jZXNz aW5nIG1vZGVsICh3aGljaCBpcyB3aGF0IGVuYWJsZXMgZ2VuZXJpYyBkZWNvZGVycykuICBIZXJl LCBnZW5lcmljIGRlY29kZXJzIGFyZSBmcmVlIHRvIGxvc2UgdGhlIHNlcmlhbGl6YXRpb24gb3Jk ZXIgb2YgaW5jb21pbmcgbWFwcyBhbmQgdG8gYmUgY29uZnVzZWQgYnkgZHVwbGljYXRlIGtleXMg YW5kIGRyb3Agc29tZSBvZiB0aGUgcGFpcnMuDQoNCkNoYW5naW5nIHRoYXQgd291bGQgYmUgYSBz aWduaWZpY2FudCBjaGFuZ2UgdG8gQ0JPUi4gIEl0IGlzIGFsc28gbm90IHJlYWxseSBuZWNlc3Nh cnksIGFzIHdlIGFscmVhZHkgaGF2ZSB0aGUgYXJyYXkgdHlwZSBmb3Igc2VxdWVuY2VzLiAgU28g YW4gYWxpc3QgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IGFuIGFycmF5IHdoZXJlIHRoZSBldmVuIG51 bWJlcmVkIGVsZW1lbnRzIGFyZSBrZXlzIGFuZCB0aGUgb2RkIG51bWJlcmVkIG9uZXMgYXJlIHZh bHVlcy4gIChUaGUgZGlzYWR2YW50YWdlIGlzIHNsaWdodGx5IGxlc3MgY29kaW5nIGVmZmljaWVu Y3kgYXMgdGhlIGFyZ3VtZW50IGlzIHR3aWNlIGFzIG11Y2ggYXMgZm9yIG1hcHMsIGFuZCB0aGUg cG9zc2liaWxpdHkgdG8gZW5jb2RlIGFuIG9kZCBudW1iZXIgb2YgZWxlbWVudHMgd2hpY2ggY2Fu 4oCZdCBiZSBtYXBwZWQgaW50byBwYWlycy4gIE5vdCByZWFsbHkgYmlnIHByb2JsZW1zIGluIHRo ZSBtYWpvcml0eSBvZiBjYXNlcy4pDQoNCk9mIGNvdXJzZSBJIGxpa2UgcHJvZ3JhbW1pbmcgZW52 aXJvbm1lbnRzIHRoYXQgcHJvdmlkZSBvcmRlcmVkIG1hcHMsIG11bHRpbWFwcyBldGMuICBDQk9S IHByb3ZpZGVzIG1hbnkgd2F5cyB0byBzZXJpYWxpemUgdGhlc2UgKGFuZCBtYXliZSB3ZSBuZWVk IGEgZmV3IG1vcmUgdGFncyB0byBiZSB1bmFtYmlndW91cyBpbiB0aGlzIHNwYWNlKS4gIEJ1dCBt YWpvciB0eXBlIDUgaXMgYWJvdXQgKHVub3JkZXJlZCkgbWFwcywgc3BlY2lmaWNhbGx5Lg0KDQpH csO8w59lLCBDYXJzdGVuDQoNCg0KPiBPbiBNYXkgMTksIDIwMTgsIGF0IDAyOjEzLCBCdXJ0IEhh cnJpcyA8YnVydF9oYXJyaXNAaG90bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSeKAmXZlIG9wZW5l ZCB0aGlzIGFzIGFuIGlzc3VlIGF0IA0KPiBodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRoDQo+IHViLmNvbSUyRmNib3It d2clMkZDQk9SYmlzJTJGaXNzdWVzJTJGMjUmZGF0YT0wMiU3QzAxJTdDJTdDMDc1M2VhZGIxYjYN Cj4gYTQzZDc5NTFkMDhkNWJkOWJhMDQ2JTdDODRkZjllN2ZlOWY2NDBhZmI0MzVhYWFhYWFhYWFh YWElN0MxJTdDMCU3QzYzNg0KPiA2MjMzOTg0NTkzNTQwMTEmc2RhdGE9NGw3NDNtTERHMDJ2SThT UHppSGdjOWNUNlpXVW9DczFIaTlpNnlMalZvVSUzRCZyDQo+IGVzZXJ2ZWQ9MCwgYnV0IGZvbGxv d2luZyBGcmFuY2VzY2HigJlzIGFkdmljZSwgZm9yd2FyZCB0aGUgdG9waWMgdG8gdGhlIA0KPiBN TCBhcyB3ZWxs4oCmIFRlcm1pbm9sb2d5IFJlZmluZW1lbnQ6IE1hcHMsIE9iamVjdHMsIGV0Y+KA pg0KPiAgDQo+IFRvIGVuaGFuY2UgY2xhcml0eSBhbmQgZXh0ZW5zaWJpbGl0eSBpbiBDQk9SYmlz LCBpdCBtaWdodCBiZSANCj4gYmVuZWZpY2lhbCB0byBhZGp1c3Qgc29tZSBvZiB0aGUgdGVybWlu b2xvZ3kgYW5kIGRlZmluaXRpb25zIHVzZWQuIEZvciBleGFtcGxlLCBpbnN0ZWFkIG9mIHRoZSBj dXJyZW50IGRyYWZ0J3M6DQo+IA0KPiBNYWpvciB0eXBlIDU6IGEgbWFwIG9mIHBhaXJzIG9mIGRh dGEgaXRlbXMuIE1hcHMgYXJlIGFsc28gY2FsbGVkIHRhYmxlcywgZGljdGlvbmFyaWVzLCBoYXNo ZXMsIG9yIG9iamVjdHMgKGluIEpTT04pLi4uDQo+ICANCj4gDQo+IGxldCdzIGNvbnNpZGVyIHNh eWluZyBzb21ldGhpbmcgbGVzcyBsb2FkZWQsIGxpa2U6DQo+IA0KPiBNYWpvciB0eXBlIDUvUEFJ UlMgLSBhbiBvcmRlcmVkIHNlcXVlbmNlIG9mIHplcm8gb3IgbW9yZSBrZXktdmFsdWUgcGFpcnMu Li4NCj4gIA0KPiANCj4gVGhpcyBpbGx1c3RyYXRlcyBhIG51bWJlciBvZiBzaGlmdHMgaW4gd29y ZGluZyBhbmQgaW50ZW50IHdoaWNoIEkgcHJvcG9zZToNCj4gDQo+IAnigKIgSXQncyBzaW1wbGVy IGFuZCBsZXNzIHJlc3RyaWN0aXZlLiBGb3IgZXhhbXBsZSwgaXQgZG9lcyBub3QgcHJldmVudCBt dWx0aW1hcHMgZnJvbSBiZWluZyByZXByZXNlbnRlZCB3aXRoIGEgcHJvcGVybHkgdGFnZ2VkIDUv UEFJUlMgZGF0YSBpdGVtLiBNdWx0aW1hcHMgY2FuIGJlIHF1aXRlIHVzZWZ1bCAoSFRUUCBhbmQg Q29BUCBwcm90b2NvbCBoZWFkZXJzIGFyZSBtdWx0aW1hcHMpLCBidXQgaXQgaXMgcmVhc29uYWJs ZSB0byBsaW1pdCB0aGVtIGFzIGEgdGFnZ2VkIGV4dGVuc2lvbiB0byBDQk9SIChzZWUgYmVsb3cu KQ0KPiAJ4oCiIFRlcm1zIGxpa2UgbWFwcywgdGFibGVzLCBkaWN0aW9uYXJpZXMsIGhhc2hlcyBh bmQgb2JqZWN0cyBhcmUgLmFic3RyYWN0IGNvbmNlcHRzIHRoYXQgZnVydGhlciByZXN0cmljdCBh bGxvd2VkIGNvbnRlbnQgb2YgdGhlIDUvUEFJUlMgbWFqb3IgdHlwZSwgdGhleSBhcmUgbm90IHN5 bm9ueW1zIGZvciBpdC4gVGhlIGRldGFpbHMgb2YgaG93IHRob3NlIGFic3RyYWN0IHR5cGVzIGJl aGF2ZSBpcyBzdWJqZWN0IHRvIHNvbWUgYW1iaWd1aXR5LCBzbyBpdCdzIGJldHRlciBub3QgdG8g dXNlIHRoZW0gaW4gZGVmaW5pbmcgdGhlIG1ham9yIHR5cGUuIENCT1IgdGFncyBjYW4gYmUgdXNl ZCB0byBpZGVudGlmeSB3aGljaCBhYnN0cmFjdCB0eXBlIGlzIGludGVuZGVkLg0KPiAJ4oCiIENC T1IgbWFqb3IgdHlwZXMgc2hvdWxkIGJlIHZpc3VhbGx5IGRpc3RpbmN0IGZyb20gdGhlIGFic3Ry YWN0IHR5cGVzIGJlY2F1c2UgbWFqb3IgdHlwZSBhbG9uZSBkb2VzIG5vdCBkZXRlcm1pbmUgdGhl IGFic3RyYWN0IHR5cGUgb2YgYW4gaXRlbTsgdGFncyBjYW4gbW9kaWZ5IHRoZSBhYnN0cmFjdCB0 eXBlLiBDb25zaXN0ZW50bHkgdXNpbmcgYm90aCB0aGUgbWFqb3IgdHlwZSBudW1lcmljIHZhbHVl IGFuZCBhbiBhc3NvY2lhdGVkIG5hbWUgKGluIGNhcHMpIHdvdWxkIGhlbHAgbWFrZSB0aGUgZGlm ZmVyZW5jZSBjbGVhci4NCj4gCeKAoiBTYXlpbmcgNS9QQUlSUyBpcyBvcmRlcmVkIHNpbXBseSBy ZWZsZWN0cyByZWFsaXR5LCBpbiBhIENCT1IgYnl0ZSBzdHJlYW0gdGhleSBtdXN0IGJlIGluIHNv bWUgb3JkZXIsIGJlY2F1c2UgaXQgaXMgYSBzZXJpYWxpemF0aW9uIGZvcm1hdC4gRWxpbWluYXRp bmcgdGhlIGtleSB1bmlxdWVuZXNzIHJlcXVpcmVtZW50IGZyb20gdGhlIG1ham9yIHR5cGUgYWxs b3dzIGVuY29kaW5nIG1vcmUgdHlwZXMsIGUuZy4gbXVsdGktbWFwcy4NCj4gSG93ZXZlciwgaXQg d291bGQgc3RpbGwgYmUgZGVzaXJhYmxlIHRvIGRlZmluZSBob3cgYW4gdW50YWdnZWQgNS9QQUlS UyBhY3RzIGJlaGF2ZSB3aXRoIGdyZWF0ZXIgc3BlY2lmaWNpdHkuIEZvciBleGFtcGxlLCB0byBh ZGRyZXNzIHRoZSBpc3N1ZSBvZiBrZXkgZXF1aXZhbGVuY2UgYW5kIGNhbm9uaWNhbGl6YXRpb24s IGl0IGNvdWxkIGJlIHZlcnkgdXNlZnVsIGZvciBhbiBVTlRBR0dFRDUvUEFJUlMgdG8gYWRvcHQg dGhlIEVDTUFTY3JpcHQvSlNPTiBvYmplY3QgcmVzdHJpY3Rpb25zIHRoYXQga2V5cyBiZSBsaW1p dGVkIHRvIHVuaXF1ZSBudW1iZXJzIGFuZCB0ZXh0IHN0cmluZ3MuIEhpZ2hseSBjb25zdHJhaW5l ZCBlbnZpcm9ubWVudHMgbWF5IGhhdmUgdHJvdWJsZSBzdXBwb3J0aW5nIGFueXRoaW5nIG1vcmUg Z2VuZXJhbCwgYnV0IHRoYXQgc2hvdWxkIG5vdCByZXN0cmljdCB0aGUgY29udGVudCBvZiBhIHRh Z2dlZCA1L1BBSVJTIGNvbGxlY3Rpb24sIHdoaWNoIG1pZ2h0IGFsbG93IGZvciB0aGUgdXNlIG9m IGEgTWFwIHRhZyB0aGF0IGNvdWxkIGltcGx5IGZ1bGwgZmxleGliaWxpdHkgb2YgZW5jb2Rpbmcg bm9uLXN0cmluZy9udW1iZXIga2V5cywgd2hpbGUgYSBNYXAgdGFnZ2VkIG9iamVjdCBtaWdodCBv YmV5IGRpZmZlcmVudCBrZXktZXF1aXZhbGVuY2UgYW5kIGNhbm9uaWNhbGl6YXRpb24gcnVsZXMs IHdpdGggZ3JlYXRlciBvdmVyaGVhZCwgZm9yIGV4YW1wbGUgdGhlIGJ5dGUgd2lzZSBsZXhpY29n cmFwaGljIG9yZGVyIG5vdyBwcm9wb3NlZC4NCj4gDQo+IEVDTUFTY3JpcHQgb2JqZWN0IENhbm9u aWNhbGl6YXRpb24gT3JkZXINCj4gDQo+IE1vZGVybiBFQ01BU2NyaXB0IG9iamVjdHMgYXJlIGRl ZmluZWQgd2l0aCBzb21lIGxpdHRsZS1rbm93biBiZWhhdmlvciB0aGF0IGNvdWxkIHJlYWxseSBo ZWxwIGJyaW5nIHRvIHNvbWUgb2YgdGhlIHRob3JueSBjYW5vbmljYWxpemF0aW9uIGlzc3Vlcy4g RUNNQVNjcmlwdCBvYmplY3RzIGFyZSBub3QgaGFzaGVzLCB0aGVpciBwcm9wZXJ0aWVzIGFyZSBv cmRlcmVkLiBCdXQgdGhlIG9yZGVyIGNhbiBzdXJwcmlzZSBzb21lIHBlb3BsZSwgdGhlIGtleXMg KGluIG9yZGVyKSBhcmU6DQo+IA0KPiAJ4oCiIE5vbi1uZWdhdGl2ZSBudW1iZXJzIGtleXMgaW4g YXNjZW5kaW5nIG9yZGVyOyBmb2xsb3dlZCBieQ0KPiAJ4oCiIFN0cmluZ3Mga2V5cyAoaW5jbHVk aW5nIG5lZ2F0aXZlIG51bWJlcnMpIGluIHRoZSBvcmRlciB0aGV5IHdlcmUgYWRkZWQgdG8gdGhl IG9iamVjdDsNCj4gCeKAoiBFQ01BU2NyaXB0IFN5bWJvbHMgKHdoaWNoIHRoZW1zZWx2ZXMgd291 bGQgaGF2ZSB0byBiZSB0YWdnZWQgaW4gDQo+IENPQkFSKSBCeSBhZG9wdGluZyB0aGUgYWJvdmUg cnVsZSBhcyBhIFNIT1VMRCBmb3IgY2Fub25pY2FsIG9iamVjdHMgKFVOVEFHR0VEIDUvUEFJUlMp LCB3ZSBnYWluIHNldmVyYWwgYWR2YW50YWdlczoNCj4gDQo+IAnigKIgSW4gQ0JPUiBiYXNlZCBz dGFuZGFyZHMgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyBbZS5nLiBDQk9SIE9iamVjdCBT aWduaW5nIGFuZCBFbmNyeXB0aW9uIChDT1NFKV0sIHN0YW5kYXJkaXplZCBub24tbmVnYXRpdmUg aW50ZWdlciBrZXlzIHNvcnQgZmlyc3QuIEEgaGlnaGx5IGNvbnN0cmFpbmVkIGltcGxlbWVudGF0 aW9uIG9mIENPU0UgbWlnaHQgY2hvb3NlIHRvIGludGVycHJldCBvbmx5IHRoZSBub24tbmVnYXRp dmUgaW50ZWdlciBrZXlzIGluIGFzY2VuZGluZyBvcmRlciBhbmQgc2tpcCBvdXQgd2hlbiBvdGhl ciBrZXkgdHlwZXMgYXJlIGRldGVjdGVkLg0KPiAJ4oCiIFVuaXF1ZW5lc3MgY29uc3RyYWludHMg YW5kIGNhbm9uaWNhbCBvcmRlciBvZiBrZXlzIG1hZGUgdXAgb2Ygb3RoZXIgdHlwZXMgYmVjb21l cyBhbiBhcHBsaWNhdGlvbi1sZXZlbCBjb25jZXJuLiBIb3dldmVyLCBhcHBsaWNhdGlvbnMgdGhh dCBoYW5kbGUgZXhpc3RpbmcgZGF0YSBpbiBhIHNvbWUgZXhpc3RpbmcgY2Fub25pY2FsIG9yZGVy LCBzaG91bGQgYmUgYXV0b21hdGljIGJlY2F1c2UgdGhlIG9yZGVyIGlzIHByZXNlcnZlZC4NCj4g TW9zdCBpZiBub3QgYWxsIGR5bmFtaWMgbGFuZ3VhZ2VzIHVzZSB0aGUgb3JkZXJlZCBtYXAgZm9y IG9iamVjdCBwcm9wZXJ0aWVzIChyYXRoZXIgdGhhbiB1bm9yZGVyZWQpIGJlY2F1c2UgaXQgY2Fu IGxlYWQgdG8gbXVjaCBiZXR0ZXIgcGVyZm9ybWFuY2UgdXNpbmcgSklUIGNvbXBpbGVyIHRlY2hu b2xvZ3kuIE1vZGVybiB2ZXJzaW9ucyBvZiBFQ01BU2NyaXB0IGhhcyBhIHNlcGFyYXRlIE1hcCB0 eXBlIChzaW5jZSBFUzIwMTYpIHdpdGggY2FwYWNpdHkgZm9yIGEgd2lkZXIgdmFyaWV0eSBvZiBr ZXlzIChlLmcuIG9iamVjdHMgYW5kIGFycmF5cyBjYW4gYmUgdXNlZCBhcyBrZXlzKSwgYnV0IGlu dGVyZXN0aW5nbHkgaXQgY2hvb3NlcyB0byBkZWZpbmUgZXF1YWxpdHkgYW5kIHVuaXF1ZW5lc3Mg Y29uc3RyYWludHMgZm9yIG1hcCB0eXBlcyB0byBiZSBiYXNlZCBvbiByZWZlcmVuY2UgZXF1YWxp dHkgKGlkZW50aXR5KSwgbm90IHZhbHVlIGVxdWFsaXR5Lg0KPiANCj4gTWlycm9yaW5nIEVDTUFT Y3JpcHQncyBvcmRlcmluZyBhbmQgdW5pcXVlbmVzcyBjb25zdHJhaW50IHJ1bGVzIGZvciB1bnRh Z2dlZCA1L1BBSVJTIG1pZ2h0IGltcG9zZSBzb21lIGFkZGl0aW9uYWwgb3ZlcmhlYWQgaW4gaW1w bGVtZW50YXRpb25zIGluIG90aGVyIGxhbmd1YWdlcywgYnV0IGZvciB0aGUgY29tbW9uIGNhc2Vz IChrZXkgaXNhIHN0cmluZyBhbmQga2V5IGlzYSBub24tbmVnYXRpdmUtaW50ZWdlcikgaXQgcHJv dmlkZXMgYSBmYWlybHkgbG93IG92ZXJoZWFkIGFwcHJvYWNoIGltcGxlbWVudGFibGUgaW4gbW9z dCAoaWYgbm90IGFsbCkgZW52aXJvbm1lbnRzLg0KPiANCj4gRGVmaW5pbmcgdGhlIENCT1IgRGF0 YSBNb2RlbCBpbiBjb21tb24gV2ViIEluZnJhc3RydWN0dXJlIHRlcm1pbm9sb2d5DQo+IA0KPiBJ IHdvdWxkIGFsc28gbGlrZSB0byBwcm9wb3NlIGRlZmluaW5nIHRoZSBDQk9SIGRhdGEgbW9kZWwg aW4gdGVybXMgZmFtaWxpYXIgdG8gd2ViIGRldmVsb3BlcnMuIEZvciB0aGlzIHB1cnBvc2UsIHRo ZSBXSEFUV0cgSW5mcmFzdHJ1Y3R1cmUgTGl2aW5nIFN0YW5kYXJkIGluY2x1ZGVzIHVzZWZ1bCBz ZXQgb2YgZGVmaW5pdG9ucyB0aGF0IGluY2x1ZGUgbW9zdCBvZiB0aGUgY29uY2VwdHMgbmVlZGVk LiBSZWZlcmVuY2luZyB0aGF0IGRvY3VtZW50IGluZm9ybWF0aW9uYWxseSwgYW5kIHNlbGVjdGl2 ZWx5IGNvcHlpbmcgc29tZSBvZiB0aGUgZGVmaW5pdGlvbnMgd2UgbmVlZCBpbnRvIENCT1JiaXMg c2VlbXMgYXBwcm9wcmlhdGUgd2l0aCByZWdhcmQgdG8gY2xhcml0eSBhbmQgaW50ZWxsZWN0dWFs IHByb3BlcnR5LiBGb3IgZXhhbXBsZSwgdGhlIGFic3RyYWN0IGNvbmNlcHRzIG9mIHRoZSBwYWly LCB0dXBsZSwgYW5kIHN0cnVjdCB0aGF0IG1heSBiZSB1c2VmdWwgZm9yIGJvdGggQ0JPUiBhbmQg Q0RETCBhbHJlYWR5IGV4aXN0IHRoZXJlLiBGdXJ0aGVybW9yZSBtb3JlIGZyZXF1ZW50bHkgdXNl ZCB0ZXJtcyBzdWNoIGFzIHN0cmluZyBhbmQgYnl0ZSBzZXF1ZW5jZSwgYW5kIHRoZSBkZWZpbml0 aW9ucyB0aGVyZSBoYXZlIGJlZW4gY2FyZWZ1bGx5IHZldHRlZCByZWdhcmRpbmcgc2VjdXJpdHkg Y29uY2VybnMsIGZvciBleGFtcGxlLCBleGNsdWRpbmcgc3Vycm9nYXRlIGNvZGUgcG9pbnRzIGlu IFVURi04Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBDQk9SIG1haWxpbmcgbGlzdA0KPiBDQk9SQGlldGYub3JnDQo+IGh0dHBzOi8vZXVyMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy4N Cj4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZjYm9yJmRhdGE9MDIlN0MwMSU3QyU3 QzA3NTNlYWRiMWI2YTQzZA0KPiA3OTUxZDA4ZDViZDliYTA0NiU3Qzg0ZGY5ZTdmZTlmNjQwYWZi NDM1YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2MzY2MjMzDQo+IDk4NDU5MzU0MDExJnNkYXRhPWF6 MFBieHhaNHpmeUF4eGx5T2ElMkJQVXNJVSUyQjJKR0J1RnhqYU5kbkxaOERzJTNEJnINCj4gZXNl cnZlZD0wDQoNCg== From nobody Thu May 24 06:26:34 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDCE12E8AD; Thu, 24 May 2018 06:26:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cbor@ietf.org, cbor-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152716839259.29976.7428315788181302444.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2018 06:26:32 -0700 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request for IETF 102 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 13:26:33 -0000 A new meeting session request has just been submitted by Barry Leiba, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: artarea dispatch secdispatch saag extra jmap uta dmarc dcrup iasa2 core ace t2trg Second Priority: suit lwig anima 6tisch Third Priority: acme roll detnet sacm lpwan dots People who must be present: Carsten Bormann Barry Leiba Alexey Melnikov Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with ART and IoT-related BoFs Please avoid Friday: one chair has to leave on Thursday night --------------------------------------------------------- From nobody Thu May 24 19:54:25 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D295D126BF3 for ; Thu, 24 May 2018 19:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.211 X-Spam-Level: X-Spam-Status: No, score=-18.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uwprf7kgdC8 for ; Thu, 24 May 2018 19:54:21 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5A01200F1 for ; Thu, 24 May 2018 19:54:21 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id e20-v6so4779619iof.4 for ; Thu, 24 May 2018 19:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PCHi/lteaD0Ms3tc67+LG/D0ldC9ijJs207V6H7hdv4=; b=uhaRvv73qocdhKlNcWGoEW+C87azMxliT3LHjEXwHTKBsudqNPIKIQQ6cRe2YABflz 7uEOcWFIucHKFyQbg7jFf76Aa27yC20AUhOB7qe57H55/aPacY0gaG6umBMKyzSeIV0K RoMZtcWRawF/+D+wOD+ZBBV/ZVjNFZEWj1JlBTesI9oH/qRW30aW82za8AkjlxF95jR1 HqUcww6O1VCMoMfmezRczorYfZXpx5FX6cawXTgJ0juUsOxsw5DT1LP81ZnSfvxtgqAB E5dH07/06Ind9dnjzXzo72KnMWWR500FXz12BE1dYf11uOvO8NB85mqiOfpFgrLBVL6O 1W5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PCHi/lteaD0Ms3tc67+LG/D0ldC9ijJs207V6H7hdv4=; b=di7IA7ml8R/YKTT8iHgckjlHqz96/cYAI6AOiTUpUg9D2Yh3zqTznSSuCf2KIxVBHc bfVq7XY64cLOTtM2bubygc1KqsaVg9MCRbF3KDBAkefC77Yj5VnwGEW5lcnzO5VyEsh8 2/2OPJyhk2g5nW4o4vnc7HYVhs+Z5kSNTLdPi4VVg7Sm7Kpi2wju3yrlMNKqITZoF9MG n2Xz9FTegGyKQTVI7ZVy8jym/TpWRzndgkVl70EqbjWqx2Xb0rtuN6POJvqalelcWFMw Y8H+NtntCHdtDljcmdIj7CmwmBoCFfjUCf5V8Fz5lKOy1qzemQ2dwGf92p+W8qsskPG/ K3Dw== X-Gm-Message-State: ALKqPwf5cfdvjGuCLJz5WMKzqGQgi0oEzk9jan9iAtRdHuSBTnbb24aK dNb8BBeLg6Mppnmnsac4ZcNh0ZUQuGjBz+ITfjtMRiTqWc8= X-Google-Smtp-Source: ADUXVKLLECJnpPMzV6y8hM3TmBKC1/2C3kEEyhey7VwJrY0QBAyc2k3fBfeAiofVgh28hMj07z5DTti/gvpAwccJkPA= X-Received: by 2002:a6b:9e42:: with SMTP id h63-v6mr474694ioe.30.1527216860562; Thu, 24 May 2018 19:54:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 24 May 2018 19:54:07 -0700 Message-ID: To: Carsten Bormann Cc: cbor@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cbor] PR17 -- Re: Making CBOR parsing more rigorous X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 02:54:24 -0000 Sorry for my delay in responding to this. On Thu, Apr 5, 2018 at 10:03 AM Carsten Bormann wrote: > On Mar 23, 2018, at 18:04, Jeffrey Yasskin wrote: > > > > https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define which kinds of CBOR parsers need to detect which errors in the encoded data, and which errors are recoverable. > There are lots of changes there. > I like identifying the value derived of the head (first byte plus any additional bytes that go into the additional information) of a data item (what is currently called the =E2=80=9Cunsigned integer=E2=80=9D in your te= xt) by name. If =E2=80=9Cargument=E2=80=9D is the best we can do, let=E2=80=99s go for it. Done. > > The basic idea is to classify encoded CBOR data into valid, invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed categories, and then use that in this and derived specifications to describe parser behavior precisely. > I don=E2=80=99t know that we need all these. > I think that the impetus for this change stems from a misreading of Section 3.3. > This Section lists things to check for in a generic parser, but also gives some advice on processing damaged data. > With some malice, that can be read as specifying the soupification of CBOR, but that was never the intention (and I haven=E2=80=99t met anyone mi= sreading it that way). Specifically, there is no intention to require specific methods of salvaging (or making the standard behavior depend on it). I'd be happy to have this change declare that all ill-formed items are fatally ill-formed. Does that match your goals? I think we do need the separate "valid" and "invalid-but-well-formed" categories since a generic parser can't distinguish those for a tag it doesn't understand. > So I think the editorial improvement would be to indicate more clearly in 3.3 what is about consistency requirements that must be checked (and violate wellformedness if they fail) and what is about potential degraded processing in the presence of an error. I don't follow this well enough to propose wording for it, sorry. Could you= ? Jeffrey From nobody Fri May 25 11:19:15 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B941127286 for ; Fri, 25 May 2018 11:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.952 X-Spam-Level: X-Spam-Status: No, score=-9.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9evvK1gHri8O for ; Fri, 25 May 2018 11:19:11 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3760C1275AB for ; Fri, 25 May 2018 11:19:11 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z6-v6so7902311iti.4 for ; Fri, 25 May 2018 11:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zk6PP6RK4aSJ/dohpg0xTV6ww/ihkf1epxBdQ4B54mk=; b=DgK5rMIdwvzwUrLK1+XQnqg5gKx7QHutn6MqtoXoDdG8BIQASEFzUET75aUdtFD89W o34BA8fBRcCgHMGHY4lXj9D/mm9hSuNMhejLcg9UI/MkzuhaDWazlhQe4dGPkCRqOgfK ZlNpZ39J2hJFWgayyoIeV/QDvpx0nTAMLuTnU= 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=zk6PP6RK4aSJ/dohpg0xTV6ww/ihkf1epxBdQ4B54mk=; b=RbJApwzSOWduqDV/PsQkV7eSfzpOSbbuNtoUo0ptQNOMAWXa4WC9CN8bpsCzdDu8uh Qtjkb1cJV2qaVkmRV7woiYFQlw6VsFMuCluiY/GG+TbYy5Yusxn5n3bQ0v/xbdAMzuZI zxASNcUwxahvkaAjAoia9xZiwkdPXfIw/07vt68c8JSaQWZjb6RoxrVc3Os1fOonOiw0 9HM7rijMx8UFbMKX37sm0Rr6ExpvoCW3DsLeL6HUiOtpidvcVh/6fYV3ZIV3YRIabYQb UkWfIJ/v+6BGmc49g5c6+RrDFpHqIJP3/RWFnv6A3gEiQj441p28OiZAtbMJqE1pZImt HWYg== X-Gm-Message-State: ALKqPwcPxVAij42CbBTYIU2Sfg2XehcJMXNcTnqTEGL0FHB81BRlhBMd c2HdxKuVJSvSfBs5gUoxZjJBfWvzk637vWmUeoka0Q== X-Google-Smtp-Source: ADUXVKLVNORbKZlKVUyjazSQNq78BtMuVWIqEyepLqqL3zh7Jm4aOPIyyJ7LLs65513Y3KueCkw2KbVbXQhAedWtOu8= X-Received: by 2002:a24:7512:: with SMTP id y18-v6mr3465068itc.31.1527272349939; Fri, 25 May 2018 11:19:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Fri, 25 May 2018 11:18:58 -0700 Message-ID: To: Francesca Palombini Cc: cbor@ietf.org, draft-ietf-cbor-7049bis@ietf.org, cbor-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e57ff7056d0bcd88" Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 18:19:14 -0000 --000000000000e57ff7056d0bcd88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My impression of the state of these PRs is: On Thu, Apr 26, 2018 at 7:14 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi all, > > > > In order to progress the draft, I=E2=80=99d like you to take a look at Je= ffrey=E2=80=99s > proposals (quoted selected text from his mail below). > > > > Only PR17 has gotten one comment so far (let=E2=80=99s discuss it further= ). Note > that the PR were submitted more than a month ago, if I hear no objections > to them before the 11th of May, we=E2=80=99ll ask the editors to go ahead= and > merge them, so please take a look and speak up. Even a =E2=80=9C+1=E2=80= =9D is useful. > > > > Big PR: > > https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define > which kinds of CBOR parsers need to detect which errors in the encoded > data, and which errors are recoverable. > Still under discussion. > https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds > of tagged items are valid. > The only objection misunderstood which text I removed, so this is probably ok to merge. Its description of tag 35 is still somewhat ambiguous because PCRE and ECMAScript have different sets of valid regular expressions, but I think it's still an improvement over what was there before. Minor PR: > > https://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data > Models section. > No comments at all, and this is probably uncontroversial. > https://github.com/cbor-wg/CBORbis/pull/19 fixes an example of Javascript > being unable to distinguish strings from numbers when they're used as map > keys > One comment from Jim led to me updating the ECMAScript reference. > https://github.com/cbor-wg/CBORbis/pull/20/files changes a statement that > depending on map order "would be very bad practice" in protocols using CB= OR > to a statement that these protocols "MUST NOT" do that. > Jim wondered whether declaring a map ordering to be an error constitutes a change to the semantics based on ordering, and I've changed the text to be clear that it's allowed. Thanks, Jeffrey --000000000000e57ff7056d0bcd88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My impression of the state= of these PRs is:

On Thu, = Apr 26, 2018 at 7:14 AM Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi all,

=C2=A0

In order to progress the draft, I=E2=80=99d like you= to take a look at Jeffrey=E2=80=99s proposals (quoted selected text from h= is mail below).

=C2=A0

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

=C2=A0

Big PR:

https://github.= com/cbor-wg/CBORbis/pull/17 has a lot of changes to defin= e which kinds of CBOR parsers need to detect which errors in the encoded data, and which errors are recoverable.


Still under discussion.
=C2=A0
=

https://github.= com/cbor-wg/CBORbis/pull/18 defines when the known kinds = of tagged items are valid.=C2=A0


The only objection misunderstood which text I removed, so this is pro= bably ok to merge. Its description of tag 35 is still somewhat ambiguous be= cause PCRE and ECMAScript have different sets of valid regular expressions,= but I think it's still an improvement over what was there before.

Minor PR:

https://github.= com/cbor-wg/CBORbis/pull/14 removes the duplicate Data Mo= dels section.


No comments a= t all, and this is probably uncontroversial.
=C2=A0
<= div class=3D"m_1697052920982514427WordSection1">

<= /u>

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


One comme= nt from Jim led to me updating the ECMAScript reference.
=C2=A0

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


Jim wondere= d whether declaring a map ordering to be an error constitutes a change to t= he semantics based on ordering, and I've changed the text to be clear t= hat it's allowed.

Thanks,
Jeffrey=C2= =A0
--000000000000e57ff7056d0bcd88-- From nobody Fri May 25 15:20:02 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318BD12D7EF; Fri, 25 May 2018 15:20:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ithMrs_zOmj0; Fri, 25 May 2018 15:19:57 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC3F12D7ED; Fri, 25 May 2018 15:19:56 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 25 May 2018 15:17:06 -0700 From: Jim Schaad To: 'Jeffrey Yasskin' , 'Francesca Palombini' CC: , , References: In-Reply-To: Date: Fri, 25 May 2018 15:19:45 -0700 Message-ID: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D3F43B.D27D6F40" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI9cRTEuUAEdWimBystirPofB1SlAGsHTXHo2CoikA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 22:20:00 -0000 ------=_NextPart_000_0012_01D3F43B.D27D6F40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: CBOR On Behalf Of Jeffrey Yasskin Sent: Friday, May 25, 2018 11:19 AM To: Francesca Palombini Cc: cbor@ietf.org; draft-ietf-cbor-7049bis@ietf.org; = cbor-chairs@ietf.org Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis =20 My impression of the state of these PRs is: =20 On Thu, Apr 26, 2018 at 7:14 AM Francesca Palombini = > wrote: Hi all, =20 In order to progress the draft, I=E2=80=99d like you to take a look at = Jeffrey=E2=80=99s proposals (quoted selected text from his mail below). =20 Only PR17 has gotten one comment so far (let=E2=80=99s discuss it = further). Note that the PR were submitted more than a month ago, if I = hear no objections to them before the 11th of May, we=E2=80=99ll ask the = editors to go ahead and merge them, so please take a look and speak up. = Even a =E2=80=9C+1=E2=80=9D is useful. =20 Big PR: = https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to = define which kinds of CBOR parsers need to detect which errors in the = encoded data, and which errors are recoverable. =20 Still under discussion. =20 = https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds = of tagged items are valid.=20 =20 The only objection misunderstood which text I removed, so this is = probably ok to merge. Its description of tag 35 is still somewhat = ambiguous because PCRE and ECMAScript have different sets of valid = regular expressions, but I think it's still an improvement over what was = there before. =20 [JLS] I have no real opinion on this set of changes =20 Minor PR: = https://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data = Models section. =20 No comments at all, and this is probably uncontroversial. =20 = https://github.com/cbor-wg/CBORbis/pull/19 fixes an example of = Javascript being unable to distinguish strings from numbers when they're = used as map keys =20 One comment from Jim led to me updating the ECMAScript reference. =20 [JLS] My only problem with this has more to do with the original = language than with any changes (the problem I have is still there). I = would not block anything on the problem I have as it is probably just = me. =20 = https://github.com/cbor-wg/CBORbis/pull/20/files changes a statement = that depending on map order "would be very bad practice" in protocols = using CBOR to a statement that these protocols "MUST NOT" do that. =20 Jim wondered whether declaring a map ordering to be an error constitutes = a change to the semantics based on ordering, and I've changed the text = to be clear that it's allowed. =20 [JLS] No problems with this update =20 Thanks, Jeffrey=20 ------=_NextPart_000_0012_01D3F43B.D27D6F40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Jeffrey = Yasskin
Sent: Friday, May 25, 2018 11:19 AM
To: = Francesca Palombini = <francesca.palombini@ericsson.com>
Cc: cbor@ietf.org; = draft-ietf-cbor-7049bis@ietf.org; = cbor-chairs@ietf.org
Subject: Re: [Cbor] Progressing work on = draft-ietf-cbor-7049bis

 

My impression of the state of these PRs = is:

 

On Thu, Apr 26, 2018 at 7:14 AM Francesca Palombini = <francesca.palombini@eri= csson.com> wrote:

Hi all,

 

In order to = progress the draft, I=E2=80=99d like you to take a look at = Jeffrey=E2=80=99s proposals (quoted selected text from his mail = below).

 <= /o:p>

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

 <= /o:p>

Big = PR:

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

 

Still under discussion.

 

https://github.com/cbor-wg/CBORbis/pull/18= defines when the known kinds of tagged items are = valid. 

 

The only objection misunderstood which text I removed, = so this is probably ok to merge. Its description of tag 35 is still = somewhat ambiguous because PCRE and ECMAScript have different sets of = valid regular expressions, but I think it's still an improvement over = what was there before.

 

[JLS] I have = no real opinion on this set of changes

 

Minor = PR:

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

 

No comments at all, and this is probably = uncontroversial.

 

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

 

One comment from Jim led to me updating the ECMAScript = reference.

 

[JLS] My only problem with this has more to do with = the original language =C2=A0than with any changes (the problem I have is = still there).=C2=A0 I would not block anything on the problem I have as = it is probably just me.

 

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

 

Jim wondered whether declaring a map ordering to be an = error constitutes a change to the semantics based on ordering, and I've = changed the text to be clear that it's allowed.

 

[JLS] No = problems with this update

 

Thanks,

Jeffrey 

------=_NextPart_000_0012_01D3F43B.D27D6F40-- From nobody Fri May 25 19:08:43 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1F127201 for ; Fri, 25 May 2018 19:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AiPr3Nk-Dnz for ; Fri, 25 May 2018 19:08:39 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000045.outbound.protection.outlook.com [40.92.0.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2D41241F5 for ; Fri, 25 May 2018 19:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cK9LVpF/zg8eDdiuQVToPSa+dYO6S01aup3kaez7Uik=; b=XGlijFCK4y1qXqJ5rNp/+uqov37iV9qzaDvHdjsFkCNZXSE8GTLcVdK6r4C7e/avtscIfciuYpTSlwMsGt72aqF5VCNtO9FwOuzM5xPkCoQfpZaZ5V+SO8QTNemZx38oVge+fDxmk2YtTgcGonywmrIDbMJnkz9Wq0kv4BttRd8+jBN580WHxxXdRJPo14LMDT60ladhBu0LVYKj4X6qhq3x1pwpWfTv1mWR/5OQ0vxxNBlsYSDCs8dJC6+gtiE47hXXF56fCq9MxJ9ustj9VSOnCmj44KfG5cbTfObiEe1a475xfn4yXsqCnIHIuFhe9n2ixOmm+yPYzfiZ0J04mA== Received: from BN3NAM01FT045.eop-nam01.prod.protection.outlook.com (10.152.66.55) by BN3NAM01HT089.eop-nam01.prod.protection.outlook.com (10.152.66.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.797.11; Sat, 26 May 2018 02:08:36 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.66.58) by BN3NAM01FT045.mail.protection.outlook.com (10.152.66.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.797.11 via Frontend Transport; Sat, 26 May 2018 02:08:36 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0797.011; Sat, 26 May 2018 02:08:36 +0000 From: Burt Harris To: Carsten Bormann , "cbor@ietf.org" Thread-Topic: Consistent translations between JSON and CBOR Thread-Index: AdP0gF5N5vVwj5IZRmKPMZ109U5Yeg== Date: Sat, 26 May 2018 02:08:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:921C735F721A988EFB7ED064833F76F043422FFF3FCD9F27A4BEF50869B94A58; UpperCasedChecksum:897B591B63454DAA4B624012C4439156DFFCDBBBA7D86BDF3DB336C65488F6FD; SizeAsReceived:6851; Count:43 x-tmn: [8iHoPUCeZHLnYg96ElzbDWJBG7GCYMrs] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT089; 7:lmgYSw9BQTph4VCi17B3OGAI8kj/JTIUGUuDIhSEL8h3URptbXl8zpJngs6nb/Nlm51AP1mKRSXoKUa4fNkpnPgz42YWHKe+pD6r/nQpSFhpHvjrlFK3dy348tSD1u5m+ugmHlaZpR0sjzESdREwXbF0oDVMvGTd6xJ8p/RQNEHmnrIKaus/pbPQPSmJGMV/E9z5hAmcIFSOpWkBDcewmJzwswro4jUOJyR0rTIbG3tZ0tG+lBGOgmJ7nDEuKnhc x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:BN3NAM01HT089; x-ms-traffictypediagnostic: BN3NAM01HT089: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT089; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT089; x-forefront-prvs: 0684F80A5C x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(26005)(476003)(2501003)(5250100002)(5660300001)(3660700001)(53386004)(86362001)(59450400001)(83332001)(3280700002)(606006)(97736004)(486006)(99286004)(6506007)(7696005)(110136005)(236005)(6346003)(33656002)(8936002)(87572001)(105586002)(54896002)(6306002)(55016002)(104016004)(14454004)(9686003)(106356001)(6436002)(102836004)(2900100001)(20460500001)(25786009)(68736007)(8676002)(73972006)(81156014)(74316002)(790700001)(82202002)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT089; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: 4X3P2em5Fidh8hD5ZdyehnRi8jk6nT/S67kx0nglEUb9dFHbhq80S4JPLxogHJWA5Pn3i6ebgj8lWXbraxuJ+aO/ZzyCpnYuf8ouTjfBd9bQ1Co6/ng8nxBDgB6E2rR8hP3qAvN4o4UWPiFtOpexoAZFYz/gCnAilWGnZUfj5YE5LHgaog6G/+UcwJQwRxTN Content-Type: multipart/alternative; boundary="_000_MWHPR22MB09268815E47CEC4DE4C0DBDD92680MWHPR22MB0926namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 746da68e-d49d-4659-f6a2-08d5c2ad975f X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 746da68e-d49d-4659-f6a2-08d5c2ad975f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2018 02:08:36.6478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT089 Archived-At: Subject: [Cbor] Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 02:08:42 -0000 --_000_MWHPR22MB09268815E47CEC4DE4C0DBDD92680MWHPR22MB0926namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV04oCZcyBkaXNjdXNzIGNsYXJpZnlpbmcgdGhlIEpTT04gaW50ZXJvcCBnb2FscyBpbiBDQk9S LUJJUy4NCg0KQ2Fyc29uIHJhaXNlZCBzb21lIGdvb2QgcG9pbnRzIGVhcmxpZXIsIHNheWluZyBj ZXJ0YWluIGRlY2lzaW9ucyBoYWQgYmVlbiBtYWRlIGZvciBjb25zaXN0ZW5jeSB3aXRoIEpTT04s IGFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gdGhhdC4gICBXZSBzaG91bGQsICBlbmhhbmNlIHNlY3Rp b24gNCBvZiBSRkMgNzA0OSBkZWFsaW5nIHdpdGggdGhpcyAoaXQgaXMgY3VycmVudGx5IG5vbi1u b3JtYXRpdmUpLCBhbmQgdGhlIGxhdGVzdCBkcmFmdC1pZXRmLWNib3ItNzA0OWJpcyBzZWN0aW9u IDUgaGFzbuKAmXQgY2hhbmdlZCB0aGF0IGluIGEgbWVhbmluZ2Z1bCB3YXkuICBCb3RoIHNlY3Rp b25zIHRhY2tsZSB0aGUgcmVsYXRpb25zaGlwIHRvIEpTT04gaW4gYW4gYWQtaG9jayB3YXksIG1h a2luZyB0ZXN0aW5nIGltcGxlbWVudGF0aW9ucyBtb3JlIGRpZmZpY3VsdC4gICBJIHRoaW5rIHdl IGNhbiBpbXByb3ZlIG9uIHRoaXMgaW4gdGhlIGdvYWxzIHNlY3Rpb24gb2YgZHJhZnQtaWV0Zi1j Ym9yLTcwNDliaXMgYXMgZm9sbG93czoNCg0KDQogIDEuICBDQk9SLUJJUyBTSE9VTEQgaW5jbHVk ZSBhIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9uIGZvciB0cmFuc2xhdGluZyBhbnkgdmFsaWQgSlNP TiB0ZXh0IGludG8gQ0JPUiwgYW5kIGJhY2suDQoNCg0KDQogIDEuICBUaGUgSlNPTiAtPiBDQk9S IHRyYW5zbGF0b3IgU0hPVUxEIGJlIG5vbi1hbWJpZ3VvdXMuICAgQW55IGdpdmVuIHNlbWFudGlj YWxseSBtZWFuaW5nZnVsIEpTT04gdGV4dCBzaG91bGQgaGF2ZSBleGFjdGx5IG9uZSBzdHJhaWdo dGZvcndhcmQgQ0JPUiB0cmFuc2xhdGlvbi4gIChDQk9SIGNvbXByZXNzaW9uIHNjaGVtZXMgY2Fu IGJlIGV4Y2x1ZGVkLikNCg0KDQogIDEuICBBIENCT1IgLT4gSlNPTiB0cmFuc2xhdG9yIGZvciBz dXBwb3J0ZWQgSlNPTiB0eXBlcyBNQVkgaW52b2x2ZSBzb21lIGFtYmlndWl0eS4gIEhvd2V2ZXIg YSBKU09OIC0+IENCT1IgLT4gSlNPTiB0cmFuc2xhdGlvbiBTSE9VTEQgaW50cm9kdWNlIG1pbmlt YWwgdGV4dCBjaGFuZ2VzLCBhbGxvd2luZyBmb3IgbGltaXRlZCBmb2xsb3dpbmcgc2VtYW50aWNh bGx5LWVxdWl2YWxlbnQgY2hhbmdlczoNCg0KICAgICAqICAgTm9uLXNpZ25pZmljYW50IHdoaXRl c3BhY2Ugb3V0c2lkZSBvZiBKU09OIHN0cmluZ3MgTUFZIGNoYW5nZS4gIEUuIGcuIFsgMCwgMSwg MiBdIGNvdWxkIGhhdmUgd2hpdGVzcGFjZSBtb2RpZmllZCB0byBiZWNvbWUgWzAsMSwyXS4gIChw cmV0dHkgcHJpbnRpbmcgbG9zdCBvciBnYWluZWQpDQoNCg0KDQogICAgICogICBCYWNrc2xhc2gt ZW5jb2RlZCBjaGFyYWN0ZXIgaW4gcXVvdGVkIEpTT04gc3RyaW5ncyBNQVkgIGNoYW5nZSB0by9m cm9tIFVURi04IGVxdWl2YWxlbnRzLiAgVGhlIGV1cm8gY3VycmVuY3kgc3ltYm9sIGluIFsgIuKC oCIgXSBjb3VsZCBiZSBjaGFuZ2VkIHRvIGFuIGVzY2FwZSBzZXF1ZW5jZSBbICJcdTIwYTAiIF0s IG9yIHZpY2UgdmVyc2EuDQoNCg0KICAgICAqICAgVW5xdW90ZWQgSlNPTiBudW1iZXIgTUFZIGNo YW5nZSBpbiB2YWx1ZS1wcmVzZXJ2aW5nIHdheXMuIEUuIGcuIGlucHV0IG9mIFsxLjBdIG1pZ2h0 IGNvdWxkIGJlY29tZSBbMV0gaW4gdGhlIHJvdW5kLXRyaXBwZWQgSlNPTi4gIFF1b3RlZCBudW1l cmljIHN0cmluZ3MgU0hPVUxEIE5PVCBiZSBjaGFuZ2VkLCBzbyBbIjEuMCJdIHNob3VsZCBzdGF5 IHVuYWx0ZXJlZC4NCg0KDQoNCiAgICAgKiAgIEludmFsaWQgVW5pY29kZSBjaGFyYWN0ZXJzIGlu IEpTT04sIHdlYXRoZXIgcXVvdGVkIGFuZCBlc2NhcGVkIG9yIG5vdCwgbWF5IGJlIHJlcGxhY2Vk IHdpdGggc29tZXRoaW5nIGVsc2UsIG9yIGV2ZW4gZ2VuZXJhdGUgYW4gZXJyb3IuICAgKFNlZSB1 bnBhaXJlZCBzdXJyb2dhdGVzIGJlbG93IGlmIHlvdSB3YW50IG1vcmUgaW5mb3JtYXRpb24uKQ0K DQoNCg0KICAgICAqICAgVW5xdW90ZWQgbm9uLW5lZ2F0aXZlIG51bWVyaWMga2V5cyBpbiBhbiBt YXAgTUFZIGJlIHNvcnRlZCBpbiBhc2NlbmRpbmcgb3JkZXIgYW5kIG1vdmVkIHRoZSBmcm9udCBv ZiB0aGUgbGlzdCBvZiBrZXkvdmFsdWUgcGFpcnMuICAgRS5nLiAgezE6ICJvbmUiLCAzOiAidGhy ZWUiLCAgMjogInR3byJ9IG1pZ2h0IGJlY29tZSB7MTogIm9uZSIsICAyOiAidHdvIiwgMzogInRo cmVlIiB9Lg0KDQoNCiAgMS4gIFRoZSBDQk9SIDwtPiBKU09OIHJvdW5kLXRyaXAgb3B0aW9ucyAo YSwgYiwgYyBhbmQgZCBhYm92ZSkgTUFZIGJlIHNlbGVjdGVkIGJ5IHRyYW5zbGF0b3Igb3B0aW9u cywgb3IgKGluIHRoZSBmdXR1cmUpIHJlcHJlc2VudGVkIGJ5IHNvbWUgQ0JPUiB0YWcgc2NoZW1l IHRvIGZ1cnRoZXIgaW1wcm92ZSB0aGUgcHJlc2VydmF0aW9uIG9mIEpTT04gdGV4dCByZXByZXNl bnRhdGlvbi4NCg0KQ0JPUiBjb21wcmVzc2lvbiBzY2hlbWVzIGFyZSBub3Qg4oCcc3RyYWlnaHRm b3J3YXJk4oCdIGFuZCB0aHVzIGFyZSBleGNsdWRlZCBmcm9tICMyIGFib3ZlLCBidXQgdGhleSBz aG91bGQgc3RpbGwgYWx3YXlzIHJvdW5kLXRyaXAgZnJvbSBhbmQgdG8gSlNPTiBhcyByZXF1aXJl ZCBieSB0aGUgb3RoZXIgZ29hbHMuDQoNClByZXNlcnZpbmcgb3JkZXIgb2Yga2V5cyBpbiByb3Vu ZC10cmlwIHRyYW5zbGF0aW9uDQoNCkxpbWl0aW5nIHRoZSBKU09OIHRleHQgY2hhbmdlcyBpbiBh IHJvdW5kLXRyaXAgc2NlbmFyaW8gYXMgc3BlY2lmaWVkIGFib3ZlIG1heSBiZSBwYXJ0aWN1bGFy bHkgdXNlZnVsIHVzIGh1bWFucy4gICBDb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIGZpbGUgZXhp c3RzIGJvdGggaW4gQ0JPUiBmb3JtYXQgYW5kIEpTT04sIHdoZXJlIHRoZSBKU09OIGV4aXN0cyBz byB0aGF0IGl0IGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGh1bWFucyBhbmQgdmVyc2lvbiBjb250cm9s IHN5c3RlbXMgbGlrZSBnaXQ6DQoNCkEgaHVtYW4gYXV0aG9yIG1heSBoYXZlIGEgZ29vZCByZWFz b24gdG8gcHV0IGVudHJpZXMgaW4gYSBKU09OIG9iamVjdCBpbiBhIHBhcnRpY3VsYXIgb3JkZXIs IGZvciBleGFtcGxlIHB1dHRpbmcgdGhlIG1vc3Qg4oCcaW1wb3J0YW504oCdIGZpZWxkcyB1cCBm cm9udC4gICBNb3N0IHRvb2xzLCBpbmNsdWRpbmcgdG9vbHMgdGhhdCAoZWRpdCBKU09OIGluIHNv bWUgYXV0b21hdGVkIHdheSkgd29u4oCZdCByZS1vcmRlciB0aGUga2V5cyB3aXRob3V0IGdvb2Qg cmVhc29uLCBhbmQgdGhhdCBoZWxwcyB0aGUgY2hhbmdlcyByZWNvcmRlZCBpbiB0aGUgdmVyc2lv biBjb250cm9sIHN5c3RlbSByZW1haW4gbWluaW1hbC4NCg0KQnV0IEnigJl2ZSB3b3JrZWQgd2l0 aCBzb21lIHRvb2xzIHRoYXQgZG8gKHVuaW50ZW50aW9uYWxseSkgcmVvcmRlciBrZXlzIGluIGEg SlNPTiBvYmplY3QsIGl0cyBnZW5lcmFsbHkgY29uc2lkZXJlZCBhIGJ1ZyBieSB0aGUgdXNlcnMg ZXZlbiB0aG91Z2ggUkZDIDgyNTkgZm9ybWFsbHkgc2F5czoNCg0KQW4gb2JqZWN0IGlzIGFuIHVu b3JkZXJlZCBjb2xsZWN0aW9uIG9mIHplcm8gb3IgbW9yZSBuYW1lL3ZhbHVlDQpwYWlycywgd2hl cmUgYSBuYW1lIGlzIGEgc3RyaW5nIGFuZCBhIHZhbHVlIGlzIGEgc3RyaW5nLCBudW1iZXIsDQpi b29sZWFuLCBudWxsLCBvYmplY3QsIG9yIGFycmF5Lg0KDQpTdWNoIGJ1Z3MgaGF2ZSBsYXJnZWx5 IGJlY29tZSBhIG5vbi1pc3N1ZSBmb3IgdG9vbHMgd3JpdHRlbiBpbiBKYXZhU2NyaXB0LCBhcyBh bGwgbW9kZXJuIGltcGxlbWVudGF0aW9ucyBwcmVzZXJ2ZSB0aGUgb3JkZXIgb2YgZmllbGRzIGlu IGFuIG9iamVjdCwgd2l0aCBvbmUgbm90YWJsZSBleGNlcHRpb246ICAga2V5cyB3aGljaCBhcmUg bm9uLW5lZ2F0aXZlIG51bWJlcnMgYWx3YXlzIHNvcnQgdG8gdGhlIHRvcC4gICAgSSBzdXNwZWN0 IHRoZSByZWFzb24gZm9yIHRoZSBleGNlcHRpb24gaW4gSmF2YVNjcmlwdCBydW50aW1lcyBpcyBl eGFjdGx5IHRoZSBzYW1lIGFzIHRoYXQgbWVudGlvbmVkIGluIGRyYWZ0LWlldGYtY2Jvci03MDQ5 YmlzIHNlY3Rpb24gNC43OiBudW1lcmljIGtleXMgYXJlIG9mdGVuIHVzZWQgaW4gY2FzZXMgd2hl cmUgb3JkZXIgaXMgaW1wb3J0YW50LCBwZXJoYXBzIHRvIG5vcm1hbGl6YXRpb24gb3IgcGVyZm9y bWFuY2UuDQoNClBlcmhhcHMgdGhpcyBoZWxwcyBleHBsYWluIG15IGVhcmxpZXIgdGhvdWdodHMg dGhhdCB0aGUgZGVmYXVsdCAodW50YWdnZWQpIGRlZmluaXRpb24gb2YgQ0JPUiBtYWpvciB0eXBl IDUgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgb3JkZXItcHJlc2VydmluZyBhdCBhIHN5bnRheCBsZXZl bCwgb3IgcGVyaGFwcyBldmVuIGJldHRlciBhZG9wdCB0aGUgbGF0ZXN0IEVDTUFzY3JpcHTigJlz IHNwZWPigJlzIGRlc2NyaXB0aW9uIG9mIHRoZSBrZXktb3JkZXJpbmcgYmVoYXZpb3Igb2Ygb2Jq ZWN0cyBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgUkZDIDcwNDkgY29uY2VwdCBvZiBub3JtYWxp emF0aW9uLg0KDQpSZXNvdXJjZSBDb25zdHJhaW5lZCBTeXN0ZW1zDQoNCk9uIGEgaGlnaGx5IHJl c291cmNlIGNvbnN0cmFpbmVkIHN5c3RlbSwgZW5jb2RpbmcgQ0JPUiBvYmplY3Qgd2l0aCBzb21l IHNwZWNpZmljIChvciBjb25zaXN0ZW50KSBvcmRlcmluZyBvZiBmaWVsZHMgaXMgYW4gYWR2YW50 YWdlLiAgIFRoZXNlIHN5c3RlbXMgd2lsbCB0eXBpY2FsbHkgbm90IHVzZSBoYXNoIHRhYmxlcyB0 byBzdG9yZSBkYXRhLiAgIEFuZCB0aGUgbW9zdCByZXNvdXJjZSBjb25zdHJhaW5lZCBzeXN0ZW1z IG1heSBvcHQgZm9yIG51bWVyaWMga2V5cyBhcyBhbiBvcHRpbWl6YXRpb24sIGFuZCBjb3VsZCB0 cmVhdCBhbnkga2V5cyB0aGF0IGFyZW7igJl0IGVuY29kZWQgd2l0aCBtYWpvciB0eXBlIDAgYXMg bG93LXByaW9yaXR5IG9yIGlycmVsZXZhbnQgZGV0YWlscywgYW5kIG1pZ2h0IGJlIGFibGUgdG8g cXVpY2tseSBza2lwIHRvIHRoZSBlbmQgb2YgdGhlIG1hcCB3aXRob3V0IHJlY29yZGluZyB0aGUg a2V5cyBvciB2YWx1ZXMuDQoNClVucGFpcmVkIFVURi0xNiBzdXJyb2dhdGVzIChhZHZhbmNlZCB0 b3BpYykNCg0KSlNPTiBoYXMgYSBncmF5IGFyZWEuICAgUkZDIDgyNTkgc2VjdGlvbiA4LjIgcG9p bnRzIG91dCBhbiBhbWJpZ3VpdHkgaW4gSlNPTiBzZW1hbnRpY3MgdG8gdGhlIEpTT04gc3RyaW5n ICJcdURFQUQiLCBUaGUgSlNPTiBSRkMgc2F5cyDigJxUaGUgYmVoYXZpb3Igb2Ygc29mdHdhcmUg dGhhdCByZWNlaXZlcyBKU09OIHRleHRzIGNvbnRhaW5pbmcgc3VjaCB2YWx1ZXMgaXMgdW5wcmVk aWN0YWJsZS7igJ0gIEJ1dCB1bmRlciB0aGUgZm9ybWFsIHN5bnRheCAoQUJORikgb2YgdGhlIEpT T04gaXQgaXMgbm90IGV4cGxpY2l0bHkgZm9yYmlkZGVuLiAgICBTa2lwIGhlcmUgdG8gZW5kIGlm IHlvdXIgYnJhaW4gaXMgb3ZlcmxvYWRlZCBieSB0aGF0IGNvbmNlcHQuDQoNClRoaXMgYmFja3Ns YXNoLXByZWZpeGVkIHNlcXVlbmNlIGlzIHRlY2huaWNhbGx5IHRoZSBKU09OIHJlcHJlc2VudGF0 aW9uIG9mIGEgVVRGLTE2IHN1cnJvZ2F0ZS4gIEl0IGlzIGEgZ3JheSBhcmVhIGJlY2F1c2UgaXQg RE9FUyBOT1QgcmVwcmVzZW50IGEgdmFsaWQgVU5JQ09ERSBjaGFyYWN0ZXIsIHRoZXJlIGlzIG5v IFVURi04IGVuY29kaW5nIGl0LCBwZXIgUkZDIDM2MjkuICAgVGh1cyBJIGxpbWl0IHRoZSBwcmVz ZXJ2YXRpb24gb2YgSlNPTiBydWxlIGluICgzKShlKSBhYm92ZS4gICBCdXQgdGhlcmUgYXJlIGEg ZmV3IHRoaW5nIHdlIGNvdWxkIGRvOg0KDQoNCiAgMS4gIERlZmF1bHQgb3B0aW9uOiAgVHJlYXQg SlNPTiBzdHJpbmdzIHJlcHJlc2VudGluZyB1bnBhaXJlZCBzdXJyb2dhdGVzIGFzIGFuIGVycm9y LCBzaW5jZSBKU09OIGRvZXNu4oCZdCBkZWZpbmUgYSBtZWFuaW5nLCBldmVuIHRob3VnaCB0aGV5 IGFyZSBzeW50YWN0aWNhbGx5IGFsbG93ZWQuIFRoaXMgaXMgd2hhdCB0aGUgQ0JPUiBQbGF5Z3Jv dW5kIChodHRwOi8vY2Jvci5tZSkgZG9lcywgYW5kIElNSE8gaXQgaXMgYSBwZXJmZWN0bHkgcmVh c29uYWJsZSBvcHRpb24uICBUaGUgZXJyb3IgbWVzc2FnZSBnaXZlbiBieSB0aGUgcGxheWdyb3Vu ZCBmb3IgIlx1REVBRCIgaXMg4oCcRXhwZWN0ZWQgb25lIG9mIFs4OWFiQUJdLCBbMC03XSBhdCBs aW5lIDEsIGNvbHVtbiA1IChieXRlIDUpIGFmdGVyICJcdUTigJ0sIHdoaWNoIHNlZW1zIHRlY2hu aWNhbGx5IGNvcnJlY3QuDQoNCg0KICAxLiAgUmVwbGFjZSBhbnkgdW5rbm93biwgdW5yZWNvZ25p emFibGUgb3IgdW5yZXByZXNlbnRhYmxlIGNoYXJhY3Rlciwgd2l0aCBVK0ZGRkQg77+9IFJFUExB Q0VNRU5UIENIQVJBQ1RFUi4gIChUaGlzIGxvb3NlIHNvbWUgaW5mb3JtYXRpb24gYnV0IGl0IGlz IG5vbi1mYXRhbCwgYnV0IGl0ICBpcyBleGFjdGx5IHdoYXQgdGhlIFJFUExBQ01FTlQgQ0hBUkFD VEVSIGNvZGUgcG9pbnQgaXMgbWVhbnQgZm9yLikNCg0KDQoNCiAgMS4gIExldmVyYWdlIGNlcnRh aW4gcGFydHMgb2YgdGhpcyBKU09OIGdyZXktem9uZSB0byBkZWZpbmUgd2F5cyB0byBlbmNvZGUg Q0JPUiBkYXRhdHlwZXMgbm90IG5vcm1hbGx5IGZvdW5kIGluIEpTT04uICBGb3IgZXhhbXBsZSwg d2UgQ09VTEQgZGVmaW5lIGEgc3BlY2lhbCBpbnRlcnByZXRhdGlvbiBvZiBhIEpTT04gc3RyaW5n IHN0YXJ0aW5nIHdpdGggIlx1REI2NCIgdG8gbWVhbiB0aGUgZm9sbG93aW5nIHRleHQgaXMgYWN0 dWFsbHkgQmFzZSA2NCBlbmNvZGVkIGJpbmFyeSBkYXRhLCBsZXZlcmFnaW5nIHRvIFJGQyAzNTQ4 ISAgQSAiXHVEQjE2IiBwcmVmaXggQ09VTEQgbWVhbiBCYXNlIDE2IChoZXhhZGVjaW1hbCkgZW5j b2RlZCBiaW5hcnkuICAgVGhlcmUgYXJlIGxpdGVyYWxseSB0aG91c2FuZHMgb2YgdW5wYWlyZWQg c3Vycm9nYXRlcyB0aGF0IGFyZSBwb3NzaWJsZSB0byBnaXZlIG1lYW5pbmcgdG8gaW4gYSDigJxD Qk9SIGluIEpTT07igJ0gY29udGV4dC4gIFdoaWxlIG5vdCBhcyBtbmVtb25pYyBhcyBDQk9S4oCZ cyBkaWFnbm9zdGljIG5vdGF0aW9uLCB0aGlzIGFwcHJvYWNoIG1pZ2h0IGdpdmUgYSB3YXkgdG8g dHJhbnNsYXRlIGFueSB2YWxpZCBDQk9SIGludG8gc3ludGFjdGljYWxseSBjb3JyZWN0IEpTT04s IGFuZCBiYWNrIQ0KDQoNCg0KICAxLiAgUHJlc2VydmUgdW5wYWlyZWQgc3Vycm9nYXRlcywgcGVy aGFwcyBieSBkZWZpbmluZyBhIENCT1IgdGFnIGZvciBsYWJlbGluZyBXb2JibHkgVHJhbnNmb3Jt YXRpb24gRm9ybWF0ICAoV1RGLTguKSAgW05vdCBhIGdvb2QgaWRlYSwgV1RGLTggaXMgbm90IG1l YW50IGZvciBpbmZvcm1hdGlvbiBpbnRlcmNoYW5nZSwgYnV0IEkgaW5jbHVkZSBpdCBmb3IgY29t cGxldGVuZXNzLl0NCg0KDQo= --_000_MWHPR22MB09268815E47CEC4DE4C0DBDD92680MWHPR22MB0926namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubW9ub3NwYWNlZA0KCXttc28tc3R5bGUt bmFtZTptb25vc3BhY2VkO30NCnNwYW4uc21hbGxjYXBzDQoJe21zby1zdHlsZS1uYW1lOnNtYWxs Y2Fwczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ5MDEw MDE3MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTYx NzUzNTY2IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjE2Mjg5MjgzMjg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjExODc2NTMxNTQgMjExNDYzOTEzMCA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9 DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxldOKAmXMgZGlzY3VzcyBjbGFyaWZ5 aW5nIHRoZSBKU09OIGludGVyb3AgZ29hbHMgaW4gQ0JPUi1CSVMuJm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYXJzb24gcmFpc2VkIHNvbWUgZ29vZCBw b2ludHMgZWFybGllciwgc2F5aW5nIGNlcnRhaW4gZGVjaXNpb25zIGhhZCBiZWVuIG1hZGUgZm9y IGNvbnNpc3RlbmN5IHdpdGggSlNPTiwgYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiB0aGF0LiZuYnNw OyZuYnNwOyBXZSBzaG91bGQsICZuYnNwO2VuaGFuY2Ugc2VjdGlvbiA0IG9mIFJGQyA3MDQ5IGRl YWxpbmcgd2l0aCB0aGlzIChpdCBpcyBjdXJyZW50bHkgbm9uLW5vcm1hdGl2ZSksIGFuZCB0aGUN CiBsYXRlc3QgZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMgc2VjdGlvbiA1IGhhc27igJl0IGNoYW5n ZWQgdGhhdCBpbiBhIG1lYW5pbmdmdWwgd2F5LiZuYnNwOyBCb3RoIHNlY3Rpb25zIHRhY2tsZSB0 aGUgcmVsYXRpb25zaGlwIHRvIEpTT04gaW4gYW4gYWQtaG9jayB3YXksIG1ha2luZyB0ZXN0aW5n IGltcGxlbWVudGF0aW9ucyBtb3JlIGRpZmZpY3VsdC4mbmJzcDsmbmJzcDsgSSB0aGluayB3ZSBj YW4gaW1wcm92ZSBvbiB0aGlzIGluIHRoZSBnb2FscyBzZWN0aW9uIG9mIGRyYWZ0LWlldGYtY2Jv ci03MDQ5YmlzDQogYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPkNCT1ItQklTIFNIT1VMRCBp bmNsdWRlIGEgbm9ybWF0aXZlIHNwZWNpZmljYXRpb24gZm9yIHRyYW5zbGF0aW5nIGFueSB2YWxp ZCBKU09OIHRleHQgaW50byBDQk9SLCBhbmQgYmFjay48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5 cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPlRoZSBKU09OIC0mZ3Q7IENCT1IgdHJhbnNs YXRvciBTSE9VTEQgYmUgbm9uLWFtYmlndW91cy4mbmJzcDsmbmJzcDsgQW55IGdpdmVuIHNlbWFu dGljYWxseSBtZWFuaW5nZnVsIEpTT04gdGV4dCBzaG91bGQgaGF2ZSBleGFjdGx5IG9uZSBzdHJh aWdodGZvcndhcmQgQ0JPUiB0cmFuc2xhdGlvbi4mbmJzcDsgKENCT1IgY29tcHJlc3Npb24gc2No ZW1lcw0KIGNhbiBiZSBleGNsdWRlZC4pPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHN0YXJ0PSIzIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj5BIENCT1IgLSZn dDsgSlNPTiB0cmFuc2xhdG9yIGZvciBzdXBwb3J0ZWQgSlNPTiB0eXBlcyBNQVkgaW52b2x2ZSBz b21lIGFtYmlndWl0eS4mbmJzcDsgSG93ZXZlciBhIEpTT04gLSZndDsgQ0JPUiAtJmd0OyBKU09O IHRyYW5zbGF0aW9uIFNIT1VMRCBpbnRyb2R1Y2UgbWluaW1hbCB0ZXh0IGNoYW5nZXMsIGFsbG93 aW5nIGZvciBsaW1pdGVkDQogZm9sbG93aW5nIHNlbWFudGljYWxseS1lcXVpdmFsZW50IGNoYW5n ZXM6PGJyPg0KPGJyPg0KPG86cD48L286cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMSI+Tm9uLXNpZ25pZmljYW50IHdo aXRlc3BhY2Ugb3V0c2lkZSBvZiBKU09OIHN0cmluZ3MgTUFZIGNoYW5nZS4mbmJzcDsgRS4gZy4g WyAwLCAxLCAyIF0gY291bGQgaGF2ZSB3aGl0ZXNwYWNlIG1vZGlmaWVkIHRvIGJlY29tZSBbMCwx LDJdLiZuYnNwOyAocHJldHR5IHByaW50aW5nIGxvc3Qgb3IgZ2FpbmVkKTxvOnA+PC9vOnA+PC9s aT48L29sPg0KPC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdp bi10b3A6MGluIiBzdGFydD0iMyIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiBzdGFydD0iMiIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzEiPkJhY2tzbGFzaC1lbmNv ZGVkIGNoYXJhY3RlciBpbiBxdW90ZWQgSlNPTiBzdHJpbmdzIE1BWSAmbmJzcDtjaGFuZ2UgdG8v ZnJvbSBVVEYtOCBlcXVpdmFsZW50cy4mbmJzcDsgVGhlIGV1cm8gY3VycmVuY3kgc3ltYm9sIGlu IFsgJnF1b3Q74oKgJnF1b3Q7IF0gY291bGQgYmUgY2hhbmdlZCB0byBhbiBlc2NhcGUgc2VxdWVu Y2UgWyAmcXVvdDtcdTIwYTAmcXVvdDsgXSwNCiBvciB2aWNlIHZlcnNhLjxvOnA+PC9vOnA+PC9s aT48L29sPg0KPC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMiBs Zm8xIj5VbnF1b3RlZCBKU09OIG51bWJlciBNQVkgY2hhbmdlIGluIHZhbHVlLXByZXNlcnZpbmcg d2F5cy4gRS4gZy4gaW5wdXQgb2YgWzEuMF0gbWlnaHQgY291bGQgYmVjb21lIFsxXSBpbiB0aGUg cm91bmQtdHJpcHBlZCBKU09OLiZuYnNwOyBRdW90ZWQgbnVtZXJpYyBzdHJpbmdzIFNIT1VMRCBO T1QgYmUgY2hhbmdlZCwgc28gWyZxdW90OzEuMCZxdW90O10NCiBzaG91bGQgc3RheSB1bmFsdGVy ZWQuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3Rh cnQ9IjMiIHR5cGU9IjEiPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjQiIHR5 cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwxIGxldmVsMiBsZm8xIj5JbnZhbGlkIFVuaWNvZGUgY2hhcmFjdGVycyBp biBKU09OLCB3ZWF0aGVyIHF1b3RlZCBhbmQgZXNjYXBlZCBvciBub3QsIG1heSBiZSByZXBsYWNl ZCB3aXRoIHNvbWV0aGluZyBlbHNlLCBvciBldmVuIGdlbmVyYXRlIGFuIGVycm9yLiZuYnNwOyAm bmJzcDsoU2VlIHVucGFpcmVkIHN1cnJvZ2F0ZXMgYmVsb3cgaWYgeW91IHdhbnQNCiBtb3JlIGlu Zm9ybWF0aW9uLik8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiBzdGFydD0iMyIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFy dD0iNSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzEiPlVucXVvdGVkIG5vbi1uZWdhdGl2 ZSBudW1lcmljIGtleXMgaW4gYW4gbWFwIE1BWSBiZSBzb3J0ZWQgaW4gYXNjZW5kaW5nIG9yZGVy IGFuZCBtb3ZlZCB0aGUgZnJvbnQgb2YgdGhlIGxpc3Qgb2Yga2V5L3ZhbHVlIHBhaXJzLiZuYnNw OyZuYnNwOyBFLmcuJm5ic3A7IHsxOiAmcXVvdDtvbmUmcXVvdDssIDM6ICZxdW90O3RocmVlJnF1 b3Q7LCAmbmJzcDsyOiAmcXVvdDt0d28mcXVvdDt9IG1pZ2h0IGJlY29tZQ0KIHsxOiAmcXVvdDtv bmUmcXVvdDssICZuYnNwOzI6ICZxdW90O3R3byZxdW90OywgMzogJnF1b3Q7dGhyZWUmcXVvdDsg fS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSI0IiB0 eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj5UaGUgQ0JPUiAmbHQ7LSZndDsgSlNPTiBy b3VuZC10cmlwIG9wdGlvbnMgKGEsIGIsIGMgYW5kIGQgYWJvdmUpIE1BWSBiZSBzZWxlY3RlZCBi eSB0cmFuc2xhdG9yIG9wdGlvbnMsIG9yIChpbiB0aGUgZnV0dXJlKSByZXByZXNlbnRlZCBieSBz b21lIENCT1IgdGFnIHNjaGVtZSB0byBmdXJ0aGVyIGltcHJvdmUgdGhlIHByZXNlcnZhdGlvbg0K IG9mIEpTT04gdGV4dCByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q0JPUiBjb21wcmVzc2lvbiBzY2hlbWVzIGFyZSBub3Qg4oCcc3RyYWlnaHRmb3J3YXJk4oCd IGFuZCB0aHVzIGFyZSBleGNsdWRlZCBmcm9tICMyIGFib3ZlLCBidXQgdGhleSBzaG91bGQgc3Rp bGwgYWx3YXlzIHJvdW5kLXRyaXAgZnJvbSBhbmQgdG8gSlNPTiBhcyByZXF1aXJlZCBieSB0aGUg b3RoZXIgZ29hbHMuJm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UHJl c2VydmluZyBvcmRlciBvZiBrZXlzIGluIHJvdW5kLXRyaXAgdHJhbnNsYXRpb248bzpwPjwvbzpw PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxpbWl0aW5nIHRoZSBKU09OIHRleHQgY2hhbmdlcyBpbiBhIHJv dW5kLXRyaXAgc2NlbmFyaW8gYXMgc3BlY2lmaWVkIGFib3ZlIG1heSBiZSBwYXJ0aWN1bGFybHkg dXNlZnVsIHVzIGh1bWFucy4mbmJzcDsmbmJzcDsgQ29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgYSBm aWxlIGV4aXN0cyBib3RoIGluIENCT1IgZm9ybWF0IGFuZCBKU09OLCB3aGVyZSB0aGUgSlNPTiBl eGlzdHMgc28gdGhhdCBpdCBjYW4gYmUgZGVhbHQgd2l0aCBieQ0KIGh1bWFucyBhbmQgdmVyc2lv biBjb250cm9sIHN5c3RlbXMgbGlrZSBnaXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgaHVt YW4gYXV0aG9yIG1heSBoYXZlIGEgZ29vZCByZWFzb24gdG8gcHV0IGVudHJpZXMgaW4gYSBKU09O IG9iamVjdCBpbiBhIHBhcnRpY3VsYXIgb3JkZXIsIGZvciBleGFtcGxlIHB1dHRpbmcgdGhlIG1v c3Qg4oCcaW1wb3J0YW504oCdIGZpZWxkcyB1cCBmcm9udC4mbmJzcDsmbmJzcDsgTW9zdCB0b29s cywgaW5jbHVkaW5nIHRvb2xzIHRoYXQgKGVkaXQgSlNPTiBpbiBzb21lIGF1dG9tYXRlZCB3YXkp IHdvbuKAmXQgcmUtb3JkZXIgdGhlDQoga2V5cyB3aXRob3V0IGdvb2QgcmVhc29uLCBhbmQgdGhh dCBoZWxwcyB0aGUgY2hhbmdlcyByZWNvcmRlZCBpbiB0aGUgdmVyc2lvbiBjb250cm9sIHN5c3Rl bSByZW1haW4gbWluaW1hbC4mbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CdXQgSeKAmXZlIHdvcmtlZCB3aXRoIHNvbWUgdG9vbHMgdGhhdCBkbyAodW5pbnRlbnRp b25hbGx5KSByZW9yZGVyIGtleXMgaW4gYSBKU09OIG9iamVjdCwgaXRzIGdlbmVyYWxseSBjb25z aWRlcmVkIGEgYnVnIGJ5IHRoZSB1c2VycyBldmVuIHRob3VnaCBSRkMgODI1OSBmb3JtYWxseSBz YXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPkFuIG9iamVjdCBpcyBhbiB1bm9yZGVyZWQgY29sbGVjdGlvbiBvZiB6ZXJvIG9yIG1vcmUg bmFtZS92YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+cGFpcnMsIHdoZXJlIGEgbmFtZSBpcyBhIHN0 cmluZyBhbmQgYSB2YWx1ZSBpcyBhIHN0cmluZywgbnVtYmVyLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ Ym9vbGVhbiwgbnVsbCwgb2JqZWN0LCBvciBhcnJheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlN1Y2ggYnVncyBoYXZlIGxhcmdlbHkgYmVjb21lIGEgbm9uLWlzc3VlIGZvciB0b29s cyB3cml0dGVuIGluIEphdmFTY3JpcHQsIGFzIGFsbCBtb2Rlcm4gaW1wbGVtZW50YXRpb25zIHBy ZXNlcnZlIHRoZSBvcmRlciBvZiBmaWVsZHMgaW4gYW4gb2JqZWN0LCB3aXRoIG9uZSBub3RhYmxl IGV4Y2VwdGlvbjombmJzcDsmbmJzcDsga2V5cyB3aGljaCBhcmUgbm9uLW5lZ2F0aXZlIG51bWJl cnMgYWx3YXlzIHNvcnQgdG8gdGhlIHRvcC4mbmJzcDsmbmJzcDsmbmJzcDsNCiBJIHN1c3BlY3Qg dGhlIHJlYXNvbiBmb3IgdGhlIGV4Y2VwdGlvbiBpbiBKYXZhU2NyaXB0IHJ1bnRpbWVzIGlzIGV4 YWN0bHkgdGhlIHNhbWUgYXMgdGhhdCBtZW50aW9uZWQgaW4gZHJhZnQtaWV0Zi1jYm9yLTcwNDli aXMgc2VjdGlvbiA0Ljc6IG51bWVyaWMga2V5cyBhcmUgb2Z0ZW4gdXNlZCBpbiBjYXNlcyB3aGVy ZSBvcmRlciBpcyBpbXBvcnRhbnQsIHBlcmhhcHMgdG8gbm9ybWFsaXphdGlvbiBvciBwZXJmb3Jt YW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyB0aGlzIGhlbHBzIGV4cGxhaW4g bXkgZWFybGllciB0aG91Z2h0cyB0aGF0IHRoZSBkZWZhdWx0ICh1bnRhZ2dlZCkgZGVmaW5pdGlv biBvZiBDQk9SIG1ham9yIHR5cGUgNSBzaG91bGQgYmUgdHJlYXRlZCBhcyBvcmRlci1wcmVzZXJ2 aW5nIGF0IGEgc3ludGF4IGxldmVsLCBvciBwZXJoYXBzIGV2ZW4gYmV0dGVyIGFkb3B0IHRoZSBs YXRlc3QgRUNNQXNjcmlwdOKAmXMgc3BlY+KAmXMgZGVzY3JpcHRpb24NCiBvZiB0aGUga2V5LW9y ZGVyaW5nIGJlaGF2aW9yIG9mIG9iamVjdHMgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIFJGQyA3 MDQ5IGNvbmNlcHQgb2Ygbm9ybWFsaXphdGlvbi4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5SZXNvdXJjZSBDb25zdHJhaW5lZCBTeXN0ZW1zPG86cD48L286cD48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBhIGhpZ2hseSByZXNvdXJjZSBjb25zdHJhaW5lZCBzeXN0ZW0sIGVu Y29kaW5nIENCT1Igb2JqZWN0IHdpdGggc29tZSBzcGVjaWZpYyAob3IgY29uc2lzdGVudCkgb3Jk ZXJpbmcgb2YgZmllbGRzIGlzIGFuIGFkdmFudGFnZS4mbmJzcDsmbmJzcDsgVGhlc2Ugc3lzdGVt cyB3aWxsIHR5cGljYWxseSBub3QgdXNlIGhhc2ggdGFibGVzIHRvIHN0b3JlIGRhdGEuJm5ic3A7 Jm5ic3A7IEFuZCB0aGUgbW9zdCByZXNvdXJjZSBjb25zdHJhaW5lZCBzeXN0ZW1zDQogbWF5IG9w dCBmb3IgbnVtZXJpYyBrZXlzIGFzIGFuIG9wdGltaXphdGlvbiwgYW5kIDxpPmNvdWxkPC9pPiB0 cmVhdCBhbnkga2V5cyB0aGF0IGFyZW7igJl0IGVuY29kZWQgd2l0aCBtYWpvciB0eXBlIDAgYXMg bG93LXByaW9yaXR5IG9yIGlycmVsZXZhbnQgZGV0YWlscywgYW5kIG1pZ2h0IGJlIGFibGUgdG8g cXVpY2tseSBza2lwIHRvIHRoZSBlbmQgb2YgdGhlIG1hcCB3aXRob3V0IHJlY29yZGluZyB0aGUg a2V5cyBvciB2YWx1ZXMuJm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ VW5wYWlyZWQgVVRGLTE2IHN1cnJvZ2F0ZXMgKGFkdmFuY2VkIHRvcGljKTxvOnA+PC9vOnA+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SlNPTiBoYXMgYSBncmF5IGFyZWEuJm5ic3A7Jm5ic3A7IFJGQyA4MjU5 IHNlY3Rpb24gOC4yIHBvaW50cyBvdXQgYW4gYW1iaWd1aXR5IGluIEpTT04gc2VtYW50aWNzIHRv IHRoZSBKU09OIHN0cmluZw0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZxdW90O1x1REVBRCZxdW90OywgPC9zcGFuPg0KVGhl IEpTT04gUkZDIHNheXMgPGI+PGk+4oCcVGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVj ZWl2ZXMgSlNPTiB0ZXh0cyBjb250YWluaW5nIHN1Y2ggdmFsdWVzIGlzIHVucHJlZGljdGFibGUu 4oCdDQo8L2k+PC9iPiZuYnNwO0J1dCB1bmRlciB0aGUgZm9ybWFsIHN5bnRheCAoQUJORikgb2Yg dGhlIEpTT04gaXQgaXMgbm90IGV4cGxpY2l0bHkgZm9yYmlkZGVuLiZuYnNwOyZuYnNwOyAmbmJz cDs8aT5Ta2lwIGhlcmUgdG8gZW5kIGlmIHlvdXIgYnJhaW4gaXMgb3ZlcmxvYWRlZCBieSB0aGF0 IGNvbmNlcHQuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGJhY2tzbGFzaC1wcmVm aXhlZCBzZXF1ZW5jZSBpcyB0ZWNobmljYWxseSB0aGUgSlNPTiByZXByZXNlbnRhdGlvbiBvZiBh IFVURi0xNiBzdXJyb2dhdGUuJm5ic3A7IEl0IGlzIGEgZ3JheSBhcmVhIGJlY2F1c2UgaXQgRE9F UyBOT1QgcmVwcmVzZW50IGEgdmFsaWQgVU5JQ09ERSBjaGFyYWN0ZXIsIHRoZXJlIGlzIG5vIFVU Ri04IGVuY29kaW5nIGl0LCBwZXIgUkZDIDM2MjkuJm5ic3A7Jm5ic3A7IFRodXMgSSBsaW1pdCB0 aGUgcHJlc2VydmF0aW9uDQogb2YgSlNPTiBydWxlIGluICgzKShlKSBhYm92ZS4mbmJzcDsmbmJz cDsgQnV0IHRoZXJlIGFyZSBhIGZldyB0aGluZyB3ZSBjb3VsZCBkbzogPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ RGVmYXVsdCBvcHRpb246Jm5ic3A7IFRyZWF0IEpTT04gc3RyaW5ncyByZXByZXNlbnRpbmcgdW5w YWlyZWQgc3Vycm9nYXRlcyBhcyBhbiBlcnJvciwgc2luY2UgSlNPTiBkb2VzbuKAmXQgZGVmaW5l IGEgbWVhbmluZywgZXZlbiB0aG91Z2ggdGhleSBhcmUgc3ludGFjdGljYWxseSBhbGxvd2VkLiBU aGlzIGlzIHdoYXQgdGhlDQogQ0JPUiBQbGF5Z3JvdW5kICg8YSBocmVmPSJodHRwOi8vY2Jvci5t ZSI+aHR0cDovL2Nib3IubWU8L2E+KSBkb2VzLCBhbmQgSU1ITyBpdCBpcyBhIHBlcmZlY3RseSBy ZWFzb25hYmxlIG9wdGlvbi4mbmJzcDsgVGhlIGVycm9yIG1lc3NhZ2UgZ2l2ZW4gYnkgdGhlIHBs YXlncm91bmQgZm9yICZxdW90O1x1REVBRCZxdW90OyBpcyDigJxFeHBlY3RlZCBvbmUgb2YgWzg5 YWJBQl0sIFswLTddIGF0IGxpbmUgMSwgY29sdW1uIDUgKGJ5dGUgNSkgYWZ0ZXIgJnF1b3Q7XHVE 4oCdLCB3aGljaCBzZWVtcw0KIHRlY2huaWNhbGx5IGNvcnJlY3QuPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5 cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5SZXBsYWNlIGFueSB1bmtub3duLCB1bnJlY29n bml6YWJsZSBvciB1bnJlcHJlc2VudGFibGUgY2hhcmFjdGVyLCB3aXRoIFUmIzQzO0ZGRkQNCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77+9 PC9zcGFuPiBSRVBMQUNFTUVOVCBDSEFSQUNURVIuJm5ic3A7IChUaGlzIGxvb3NlIHNvbWUgaW5m b3JtYXRpb24gYnV0IGl0IGlzIG5vbi1mYXRhbCwgYnV0IGl0ICZuYnNwO2lzIGV4YWN0bHkgd2hh dCB0aGUgUkVQTEFDTUVOVCBDSEFSQUNURVIgY29kZSBwb2ludCBpcyBtZWFudCBmb3IuKTxvOnA+ PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj5MZXZlcmFnZSBjZXJ0YWluIHBhcnRzIG9mIHRoaXMgSlNP TiBncmV5LXpvbmUgdG8gZGVmaW5lIHdheXMgdG8gZW5jb2RlIENCT1IgZGF0YXR5cGVzIG5vdCBu b3JtYWxseSBmb3VuZCBpbiBKU09OLiZuYnNwOyBGb3IgZXhhbXBsZSwgd2UgQ09VTEQgZGVmaW5l IGEgc3BlY2lhbCBpbnRlcnByZXRhdGlvbiBvZiBhIEpTT04gc3RyaW5nDQogc3RhcnRpbmcgd2l0 aCAmcXVvdDtcdURCNjQmcXVvdDsgdG8gbWVhbiB0aGUgZm9sbG93aW5nIHRleHQgaXMgYWN0dWFs bHkgQmFzZSA2NCBlbmNvZGVkIGJpbmFyeSBkYXRhLCBsZXZlcmFnaW5nIHRvIFJGQyAzNTQ4ISZu YnNwOyBBICZxdW90O1x1REIxNiZxdW90OyBwcmVmaXggQ09VTEQgbWVhbiBCYXNlIDE2IChoZXhh ZGVjaW1hbCkgZW5jb2RlZCBiaW5hcnkuJm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBsaXRlcmFsbHkg dGhvdXNhbmRzIG9mIHVucGFpcmVkIHN1cnJvZ2F0ZXMgdGhhdCBhcmUgcG9zc2libGUNCiB0byBn aXZlIG1lYW5pbmcgdG8gaW4gYSDigJxDQk9SIGluIEpTT07igJ0gY29udGV4dC4mbmJzcDsgV2hp bGUgbm90IGFzIG1uZW1vbmljIGFzIENCT1LigJlzIGRpYWdub3N0aWMgbm90YXRpb24sIHRoaXMg YXBwcm9hY2ggbWlnaHQgZ2l2ZSBhIHdheSB0byB0cmFuc2xhdGUgYW55IHZhbGlkIENCT1IgaW50 byBzeW50YWN0aWNhbGx5IGNvcnJlY3QgSlNPTiwgYW5kIGJhY2shPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iNCIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPlByZXNlcnZlIHVucGFpcmVkIHN1cnJvZ2F0ZXMsIHBlcmhhcHMgYnkgZGVmaW5p bmcgYSBDQk9SIHRhZyBmb3IgbGFiZWxpbmcNCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+ V29iYmx5IFRyYW5zZm9ybWF0aW9uIEZvcm1hdA0KPC9zcGFuPiZuYnNwOyhXVEYtOC4pJm5ic3A7 IFtOb3QgYSBnb29kIGlkZWEsIFdURi04IGlzIG5vdCBtZWFudCBmb3IgaW5mb3JtYXRpb24gaW50 ZXJjaGFuZ2UsIGJ1dCBJIGluY2x1ZGUgaXQgZm9yIGNvbXBsZXRlbmVzcy5dPG86cD48L286cD48 L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR22MB09268815E47CEC4DE4C0DBDD92680MWHPR22MB0926namp_-- From nobody Fri May 25 19:09:06 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D614127201 for ; Fri, 25 May 2018 19:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w37t6aszTMeZ for ; Fri, 25 May 2018 19:08:53 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002079.outbound.protection.outlook.com [40.92.2.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB5912E874 for ; Fri, 25 May 2018 19:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0xhd505FL5HWhwtJy0qcZblzAHC9mhaECAI2CmYWGKE=; b=SQJSZCMTIy/N07GvwH1KwzhHcPJwBp9/s93rTtHmtFFOKpz7/rAj2J09UyBAVL2xt5tw7Uh4NNmq+qF7jXtc6huuaPgL9M0LrA6D/J6Ne/YXXofdcOq8SgXAIV/FDUGFFXDvloVdLDCLcj3Lyuai1cx/0g67jbWOOpzYjKMjkFvYHAWMVRF43mOk7AaEOifzZs8po0qAMHC2tK9gzB89Ac0IXv00LbKbReMAlzZHCgg2tFMRY8VqE7yHI6dwmuAOP1WRWS4pvdO6R27gZK5XWrax+kqvkzZNggWQwzU2q6/p4+PDXtkM0yyveCzcroMjravvJKgbIpbmpWObiKuOjg== Received: from BN3NAM01FT045.eop-nam01.prod.protection.outlook.com (10.152.66.53) by BN3NAM01HT117.eop-nam01.prod.protection.outlook.com (10.152.66.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.797.11; Sat, 26 May 2018 02:08:52 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.66.58) by BN3NAM01FT045.mail.protection.outlook.com (10.152.66.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.797.11 via Frontend Transport; Sat, 26 May 2018 02:08:51 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0797.011; Sat, 26 May 2018 02:08:52 +0000 From: Burt Harris To: Jeffrey Yasskin CC: Carsten Bormann , "cbor@ietf.org" Thread-Topic: =?utf-8?B?W0Nib3JdIENCT1ItQklTIFRlcm1pbm9sb2d5IFJlZmluZW1lbnQgOiBNYXBz?= =?utf-8?B?IHZzIE9iamVjdHMsIGV0Y+KApg==?= Thread-Index: AQHT9FGSNHQklTo/w02eCG+6xqt6DqRAy1Hg Date: Sat, 26 May 2018 02:08:51 +0000 Message-ID: References: <2A7F54B1-4F6D-4037-B9F9-C982A1AF5921@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:B1D5D80D472755318622224BED2944F12D0AB8E9F0655CB2EC184D91F20C9172; UpperCasedChecksum:BC092469164C9E43F315B189E743FB7BA7F489BB2B67F2BB49A584B957EADABC; SizeAsReceived:7536; Count:46 x-tmn: [W6kzMFmB9CtkGFdhckqGPAFnC5yERXuE] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT117; 7:WoIz6nG0ChZgfTQVrrcut+63qkwfm9FEyGQ56PJW6vVkSi40MjOHXjqk2iD3pVMioVujujH52bi0vU6H+GyebVvhJCXlv0wUQFQWFTz4vKxMfUBIlo8W+H+bkWsyFhVaw+ldWE1q84HOyDmHBFa/aqHVws7rCATw9Tv5G6jsaxjcGQbR5KPdyuNNBVpJBmpxfByk8b41IBhRtR2S/mTj8gUA+iaVTiuEZBDneu5iVUy6nUcalg/FNRkXDag14jK0 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:BN3NAM01HT117; x-ms-traffictypediagnostic: BN3NAM01HT117: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT117; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT117; x-forefront-prvs: 0684F80A5C x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(25786009)(82202002)(6916009)(229853002)(97736004)(76176011)(7696005)(68736007)(105586002)(74316002)(104016004)(3280700002)(6246003)(73972006)(106356001)(790700001)(476003)(86362001)(486006)(6436002)(2900100001)(3660700001)(33656002)(8936002)(87572001)(54906003)(446003)(5660300001)(93886005)(81156014)(9686003)(14454004)(54896002)(6306002)(55016002)(102836004)(83332001)(11346002)(6346003)(4326008)(5250100002)(6506007)(99286004)(59450400001)(20460500001)(26005)(19609705001)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT117; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: NZAIs/eOEprOTypXPOSMXsF6vFx486URLhCdgvQBghjrwf7xYhZfCm3uxg4e/RwJmIk1wZC4KhpsB1Fd3kxVcQ5RKgFiO9FWufs0+4QV7W0/+wIbGBFTeOX1o6Be6JxQnBNAwAPE2QAjYE3692mQVSxPcm9d2qfdEpI0fxQQ2ysqm+p3Qg5FFZ/QvbnAHLyw Content-Type: multipart/alternative; boundary="_000_MWHPR22MB092614EF622E8B051E2DC3D792680MWHPR22MB0926namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ac07366d-11e5-4e46-ed9a-08d5c2ada095 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: ac07366d-11e5-4e46-ed9a-08d5c2ada095 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2018 02:08:52.0541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT117 Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgZXRj4oCm?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 02:08:56 -0000 --_000_MWHPR22MB092614EF622E8B051E2DC3D792680MWHPR22MB0926namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBzYWlkIGJlZm9yZSwgSeKAmWQgbGlrZSB0byBkaXNhdm93IGFueSByZWFkaW5nIG9mIG15 IGVhcmxpZXIgc3VnZ2VzdGlvbiB0aGF0IHRoZSBvcmRlcmVkL3Vub3JkZXJlZCBzZW1hbnRpY3Mg Y2hhbmdlIG9mIG1ham9yIHR5cGUgNSBjaGFuZ2UgZm9yIHRoZSBwdXJwb3NlIG9mIHRoaXMgdGhy ZWFkLiAgIFRoYXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgY29udmVyc2F0aW9uIGZyb20gdGhpcyBv bmUgb24gdGVybWlub2xvZ3kuICAgICBBbnkgcGVyY2VwdGlvbiBJ4oCZbSB0cnlpbmcgdG8gcmVk ZWZpbmUgQ0JPUiBpcyBzaW1wbHkgYSBidWcgaW4gbXkgb3duIHdyaXRpbmcgZG93biB0aG91Z2h0 cyBvbiBpbXByb3ZpbmcgQ0JPUiB0ZXJtaW5vbG9neS4NCg0KSSBhbSBpbiBhZ3JlZW1lbnQgd2l0 aCBKZWZmcmV5IFlhc3NraW4gb24gb25lIHBvaW50OiB0aGUgY3VycmVudCBuYW1lcyBvZiB0aGUg bWFqb3IgdHlwZXMgYXJlbuKAmXQgYSBfYmlnXyBwcm9ibGVtLCBidXQgdGhhdCBkb2VzbuKAmXQg bWVhbiB0aGV5IGNhbuKAmXQgYmUgX2ltcHJvdmVkXyBpbiB0aGUgQ0JPUi1CSVMgZG9jdW1lbnQu ICAgIE15IG1vdGl2YXRpb24gZm9yIHN1Z2dlc3RpbmcgdGVybWlub2xvZ3kgY2hhbmdlcyBpcyBz cGVjaWZpYyBjb25mdXNpb24gSeKAmXZlIGFjdHVhbGx5IHNlZW4gaW4gY29tbXVuaWNhdGlvbnMg YmV0d2VlbiBleHBlcmllbmNlZCBkZXZlbG9wZXJzIGFib3V0IENCT1IsIHBhcnRpY3VsYXJseSBk ZXZlbG9wZXJzIG9mIGRpdmVyc2UgYmFja2dyb3VuZHMgYnV0IHdobyBhcmUgZXhwZXJpZW5jZWQg aW4gZGF0YSBzZXJpYWxpemF0aW9uIGFuZCBrbm93bGVkZ2UgcmVwcmVzZW50YXRpb24uDQoNClRo ZSBub3RhdGlvbiBjaGFuZ2VzIEnigJl2ZSBzdWdnZXN0ZWQgZm9yIG1ham9yIHR5cGVzIGFyZSBO T1QgZm9yIHRoZSBiZW5lZml0IG9mIGEgbmV3Y29tZXIgcmVhZGluZyB0aGUgZG9jdW1lbnQsIHll dCBvYnZpb3VzbHkgdGhleSBTSE9VTEQgTk9UIGNvbmZ1c2UgYSBuZXdjb21lciwgbm9yIHNob3Vs ZCB0aGV5IHNlZW0gYSBiaWcgZGVhbCB0byBhbnlvbmUgZmFtaWxpYXIgd2l0aCBDQk9SIHRocm91 Z2ggUkZDIDcwNDkuDQpBbiBleGFtcGxlIG9mIGNvbmZ1c2luZyBiYXNlZCBvbiBjdXJyZW50IHRl cm1pbm9sb2d5OiAgaW4gYW4gZS1tYWlsIGV4Y2hhbmdlIHdpdGggYW4gZXhwZXJpZW5jZWQgQ0JP UiBpbXBsZW1lbnRvciwgaGUgc2FpZCBzb21ldGhpbmcgdGhhdCBkaWRu4oCZdCBtYWtlIHNlbnNl IHRvIG1lOg0KDQoNCiAgKiAgIEhvd2V2ZXIsIGtlZXAgaW4gbWluZCB0aGF0IGl0IGRvZXNuJ3Qg bWF0dGVyIHdoZXRoZXIgSlNPTiBoYXMgYSB0ZXh0IHN0cmluZyB0eXBlIG9yIG5vdCAtIHRoZSBx dWVzdGlvbiBoZXJlIGlzIHdoZXRoZXIgaXQgaXMgcGVybWlzc2libGUgdG8gY29udmVydCBKU09O IHN0cmluZ3MgaW50byBDQk9SIGJpbmFyeSBzdHJpbmdzLCBhbmQgdGhlIGFuc3dlciBpcyBvYnZp b3VzbHkgdGhhdCBpdCBpcyBwZXJtaXNzaWJsZSwgYXQgbGVhc3QgYnkgSUVURiBzdGFuZGFyZHMu DQoNCg0KDQpXaXRob3V0IG5hbWluZyBoaW0sIEkgcmVzcGVjdCB0aGUgYXV0aG9y4oCZcyBpbnRl bnQgaW4gc2F5aW5nIGl0LCBidXQgSSBjYW7igJl0IGFncmVlIGluIGRldGFpbC4gICAgSGVyZeKA mXMgbXkgbG9naWMgZm9yIHdhbnRpbmcgQ0JPUi1CSVMgdG8gdW5hbWJpZ3VvdXNseSBtYWtlIGhp cyBzdGF0ZW1lbnQgZmFsc2U6DQoNCg0KDQogIDEuICBKU09OIHRleHQgaXMgZW5jb2RlZCBhcyBV VEYtOCAoZGVmYXVsdCksIFVURi0xNiBvciBVVEYtMzIuICAgKFJGQyA3MTU5LCBzZWN0aW9uIDgu MSwgY2xhcmlmaWVkIGluIFJGQyA4MjU5IHNlY3Rpb24gOC4xKQ0KICAyLiAgSlNPTiBzdHJpbmdz IGFyZSBjb21wb3NlZCBlbnRpcmVseSBvZiBVbmljb2RlIGNoYXJhY3RlcnMgKFJGQyA4MjU5IHNl Y3Rpb24gOC4yKQ0KICAzLiAgQ0JPUiBtYWpvciB0eXBlIDIgaXMgZm9yIGJ5dGVzLCB3aXRob3V0 IGFueSBpbXBsaWVkIGVuY29kaW5nLiAoUkZDIDcwNDksIHNlY3Rpb24gMi4xLikNCiAgNC4gIENC T1IgbWFqb3IgdHlwZSAzIGlzIGZvciBVTklDT0RFIHRleHQgZW5jb2RlZCBhcyBVVEYtOC4gKFJG QyA3MDQ5LCBzZWN0aW9uIDIuMS4pDQogIDUuICBDQk9SIHRyZWF0cyBKU09OIHRleHQgaXMgYSBz ZXF1ZW5jZSBvZiBjaGFyYWN0ZXJzLCBub3QgZW5jb2RlZCBieXRlcyAoUkZDIDcwNDksIHNlY3Rp b24gNCwgY29uZmlybWluZyAjMiBhYm92ZS4pDQoNCg0KSUVURiBzdGFuZGFyZHMgYXJlIGdlbmVy YWxseSB2ZXJ5IHNwZWNpZmljIGFib3V0IHRoaW5ncyBsaWtlIGNoYXJhY3RlciBlbmNvZGluZ3Mu ICBZZXQgYW4gZXhwZXJpZW5jZWQgQ0JPUiBkZXZlbG9wZXIgaXMgdGVsbGluZyBtZSBpdOKAmXMg cGVyZmVjdGx5IE9LIHRvIGxvc2UgdGhlIGNoYXJhY3RlciBlbmNvZGluZyBpbmZvcm1hdGlvbiBi eSBjb252ZXJ0aW5nIEpTT04gc3RyaW5ncyBhcyBDQk9SIGJpbmFyeSBzdHJpbmdzLiAgIChOb3cg aWYgdGhlIENCT1IgYmluYXJ5IHN0cmluZyB3ZXJlIHByZWNlZGVkIGJ5IGEgdGFnIChtYWpvciB0 eXBlIDYpIGluZGljYXRpbmcgYSBzcGVjaWZpYyBjaGFyYWN0ZXIgZW5jb2RpbmcsIHN1Y2ggYXMg SVNPL0lFQyA4ODU5LTE6MTk5OCwgSSBjb3VsZCBhY2NlcHQgdGhlIGFyZ3VtZW50LCBidXQgd2Ug ZG9u4oCZdCBoYXZlIHN1Y2ggc3RyaW5nIGVuY29kaW5nIHRhZ3Mgc3BlY2lmaWVkIHlldC4pICAg SXQgbWF5IHNlZW0gYSBzbWFsbCBwb2ludCB0byBhIHBlcnNvbiB3b3JraW5nIGluIHNvbWUgc3Bl Y2lmaWMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UsIGJ1dCB3aGVuIGludGVybmF0aW9uYWwgYW5kIHBv bHlnbG90IGNvbmNlcm5zIGFyZSB0YWtlbiBpbnRvIGVmZmVjdCwgbG9vc2luZyBjaGFyYWN0ZXIg ZW5jb2RpbmcgaW5mb3JtYXRpb24gaXMgYSB2ZXJ5IGJhZCB0aGluZywgYnV0IEkgdGhpbmsgaGUg b3ZlcmdlbmVyYWxpemVkIGJlY2F1c2Ugb2YgaGlzIGxhbmd1YWdlIGJhY2tncm91bmQNCg0KU28s IGFmdGVyIHN1YnN0YW50aWFsIHJlZmxlY3Rpb24sIEkgdW5kZXJzdGFuZCB3aHkgdGhlIG9yaWdp bmFsIGF1dGhvciBzYWlkIHdoYXQgaGUgZGlkOiBoZSB3YXMgdGhpbmtpbmcgaW4gdGVybXMgb2Yg YSB2ZW5lcmFibGUgb2xkIGxhbmd1YWdlOiBQZXJsIDUuICAgKFBlcmwgaXMgc28gb2xkLCBpdCBw cmVkYXRlcyBVbmljb2RlLikgICBUaGUgcHJvYmxlbSBpbiBQZXJsIGlzIHRoZXJlIGFyZSBubyBu YXRpdmUgYmluYXJ5IChieXRlcykgdHlwZSwgYnV0IGl04oCZcyBhIGNvbW1vbiBwcmFjdGljZSB0 byBzdG9yZSBiaW5hcnkgZGF0YSBpbiDigJxzdHJpbmdz4oCdLiAgIFRoZSBQZXJsIGxhbmd1YWdl IENCT1ItWFMgcGFja2FnZSBvZmZlcnMgYSBjb25maWd1cmFibGUgb3B0aW9uIG9uIGhvdyB0byBl bmNvZGUgUGVybCBzdHJpbmdzIGluIENCT1IsIGFuZCB0aGUgZGVmYXVsdCBzZXR0aW5nIHRvIGVu Y29kaW5nIFBlcmwgc3RyaW5ncyBhcyAyIHJhdGhlciB0aGFuIDMuICAgVG8gYSBQZXJsIHByb2dy YW1tZXIsIHN0cmluZ3MgYXJlIGEgcGxhY2UgdG8gc3RvcmUgZWl0aGVyLiAgICBUaGlzIHNvcnQg b2YgY29uZnVzaW9uIHdvdWxkIGJlIHJlZHVjZWQgYnkgZWxpbWluYXRpbmcg4oCcc3RyaW5n4oCd IGZyb20gdGhlIG5hbWVzIG9mIHRoZSBtYWpvciB0eXBlcy4NCg0KDQpGb3Igbm9uLUFTQ0lJIGNh c2VzLCBjaGFyYWN0ZXIgZW5jb2RpbmcgbWF0dGVycywgYnV0IG9mdGVuIG92ZXJsb29rZWQgaW4g c2ltcGxlIGV4YW1wbGVzLiAgSSB0aGluayB0aGUgZXVybyBjdXJyZW5jeSBzaWduIChKU09OIOKA nFx1MjBhMOKAnSkgaXMgYSBnb29kIGV4YW1wbGUuICAgSXQgU0hPVUxEIGJlIGVuY29kZWQgYXMg Q0JPUiBoZXggNjMgRTIgODIgQTAsIGJlY2F1c2UgVSsyMEEwIGlzIGluIFVURi04IEUyIDgyIEEw LiBJdCBTSE9VTEQgTk9UIGJlIGVuY29kZWQgYXMgQ0JPUiBoZXggNjEgODAsIG5vciA0MSA4MCwg ZXZlbiB0aG91Z2ggaGV4IDgwIGhhcyBiZWVuIGFzc2lnbmVkIHRvIHRoZSBldXJvIGN1cnJlbmN5 IHNpZ24gaXMgaGV4IDgwIGluIGEgY29tbW9ubHkgdXNlZCBjb2RlIHBhZ2UuDQoNCg0KDQpUaGUg 4oCcTWFw4oCdIHRlcm0gZm9yIG1ham9yIHR5cGUgNSBpcyBjYW4gYmUgc2ltaWxhcmx5IGZpbGxl ZCB3aXRoIGNvbmZsaWN0aW5nIG51YW5jZSBhY3Jvc3MgYSBwb2x5Z2xvdCBjb21tdW5pdHkuICAg IFNvbWUgcHJvZ3JhbW1pbmcgZW52aXJvbm1lbnRzIGhhdmUgYSB2ZXJ5IHNwZWNpZmljIGludGVy cHJldGF0aW9uIG9mIE1hcCB3aGljaCBtYXkgbm90IG1hdGNoIHRob3NlIG9mIENCT1IuICAgRm9y IGV4YW1wbGUsIG1vZGVybiBFQ01BU2NyaXB0IHNwZWNpZmljYXRpb25zIGFuZCBKYXZhU2NyaXB0 IGltcGxlbWVudGF0aW9ucyBoYXZlIGEgbmF0aXZlIE1hcCB0eXBlIHRoYXQgKGxpa2UgQ0JPUikg c3VwcG9ydHMgbm9uLXByaW1pdGl2ZSBrZXlzIChsaWtlIGFuIGFycmF5KS4gICBQcm9ibGVtIGhl cmUgaXMgdGhhdCBidXQgdW5saWtlIFJGQyA3MDQ5LCBhIEphdmFTY3JpcHQgTWFwIGRvZXMgbm90 IGF0dGVtcHQgdG8gZGVmaW5lIHZhbHVlLWVxdWFsaXR5IG9mIHN1Y2ggbm9uLXByaW1pdGl2ZSBr ZXlzLCBzZXR0aW5nIGluc3RlYWQgZm9yIG9iamVjdCBpZGVudGl0eSBlcXVhbGl0eS4NCg0KDQoN ClRlcm1pbm9sb2d5IHdpc2UsIHNlbGVjdGluZyBhIHBsYXRmb3JtLW5ldXRyYWwgdGVybSB3aXRo IG1pbmltYWwgaW1wbGllZCBtZWFuaW5nIGZvciB0aGUgZXhpc3Rpbmcgc2VtYW50aWNzIG9mIG1l c3NhZ2UgNSwgIEkgc3RpbGwgc3VnZ2VzdCDigJxQQUlSU+KAnSBpcyBiZXR0ZXIgdGhhbiDigJxN YXDigJ0gZm9yIHRoZSBzYW1lIHJlYXNvbiBJ4oCZZCBsaWtlIHRvIHVzZSDigJxCWVRFU+KAnSBp bnN0ZWFkIG9mIOKAnGJ5dGUgc3RyaW5n4oCdLiAgVGhlIGxleGljYWwgY29udmVudGlvbiBvZiB3 cml0aW5nIGVhY2ggbWFqb3IgdHlwZSBudW1lcmljIHZhbHVlIHdpdGggYm90aCBhIG51bWJlciBh bmQgbW5lbW9uaWMgaXMgdG8gZnVydGhlciBkaXN0aW5ndWlzaCB0aGUgd29yZHMgbGlrZSBVTklD T0RFIGluIHRleHQgZnJvbSB1c2FnZSBhcyBhIG1ham9yIHR5cGUuICAgIFRodXMgY29tYmluaW5n IG90aGVyIGZlZWRiYWNrLCBJ4oCZbGwgdXBkYXRlIG15IHN1Z2dlc3Rpb25zIHRvOg0KDQoNCg0K ICAgICAgICAgICAgICAgIDAvVU5TSUdORUQNCg0KICAgICAgICAgICAgICAgIDEvTkVHQVRJVkUN Cg0KICAgICAgICAgICAgICAgIDIvQllURVMNCg0KICAgICAgICAgICAgICAgIDMvVU5JQ09ERQ0K DQogICAgICAgICAgICAgICAgNC9JVEVNUw0KDQogICAgICAgICAgICAgICAgNS9QQUlSUw0KDQog ICAgICAgICAgICAgICAgNi9UQUcNCg0KICAgICAgICAgICAgICAgIDcvT1RIRVINCg0KDQoNClRo aXM6IGEpIGF2b2lkcyBhYmJyZXZpYXRpb25zIGluIHRoZSBhYmJyZXZpYXRpb25zIGluIG1uZW1v bmljcywgYW5kIGIpIHVzZXMgcHJvcGVyIHNpbmd1bGFyL3BsdXJhbCBjYXNpbmcuICAgSeKAmW0g bm90IHBhcnRpY3VsYXJseSBoYXBweSB3aXRoIDQvSVRFTVMsIGFuZCBvbmx5IHVwZGF0ZWQgaXQg ZnJvbSA0L1NFUSB0byBhZGRyZXNzIHRoZSBjb25zaXN0ZW5jeSBwb2ludCwgYW55b25lIGhhdmUg YSBiZXR0ZXIgaWRlYT8NCg0KDQo= --_000_MWHPR22MB092614EF622E8B051E2DC3D792680MWHPR22MB0926namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDg5NTIwNjIw Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc2NjQx MTU4IDE5NzgxOTEwOTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMTIxODAwNzAyOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzQ1NjQwNDk0IDU0NTQz MDI3OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVp bjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMuMjVpbjsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDo0Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE2Mjg5MjgzMjg7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MjA3Nzc2IDIxMTQ2MzkxMzAgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDMNCgl7bXNvLWxpc3QtaWQ6MTYzNzkwNjE4NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMjkzODIwMDggMjExNDYzOTEzMCA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCW1hcmdpbi1sZWZ0OjMuMjVpbjsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN CgltYXJnaW4tbGVmdDo0Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBJIHNhaWQgYmVmb3JlLCBJ 4oCZZCBsaWtlIHRvIGRpc2F2b3cgYW55IHJlYWRpbmcgb2YgbXkgZWFybGllciBzdWdnZXN0aW9u IHRoYXQgdGhlIG9yZGVyZWQvdW5vcmRlcmVkIHNlbWFudGljcyBjaGFuZ2Ugb2YgbWFqb3IgdHlw ZSA1IGNoYW5nZSBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhpcyB0aHJlYWQuJm5ic3A7Jm5ic3A7IFRo YXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgY29udmVyc2F0aW9uIGZyb20gdGhpcyBvbmUgb24gdGVy bWlub2xvZ3kuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQogQW55IHBlcmNlcHRpb24gSeKAmW0g dHJ5aW5nIHRvIHJlZGVmaW5lIENCT1IgaXMgc2ltcGx5IGEgYnVnIGluIG15IG93biB3cml0aW5n IGRvd24gdGhvdWdodHMgb24gaW1wcm92aW5nIENCT1IgdGVybWlub2xvZ3kuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYW0gaW4gYWdyZWVtZW50IHdpdGggSmVmZnJleSBZYXNza2luIG9uIG9u ZSBwb2ludDogdGhlIGN1cnJlbnQgbmFtZXMgb2YgdGhlIG1ham9yIHR5cGVzIGFyZW7igJl0IGEg XzxpPmJpZzwvaT5fIHByb2JsZW0sIGJ1dCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZXkgY2Fu4oCZ dCBiZSBfPGk+aW1wcm92ZWQ8L2k+XyBpbiB0aGUgQ0JPUi1CSVMgZG9jdW1lbnQuJm5ic3A7Jm5i c3A7Jm5ic3A7IE15IG1vdGl2YXRpb24gZm9yIHN1Z2dlc3RpbmcgdGVybWlub2xvZ3kNCiBjaGFu Z2VzIGlzIHNwZWNpZmljIGNvbmZ1c2lvbiBJ4oCZdmUgYWN0dWFsbHkgc2VlbiBpbiBjb21tdW5p Y2F0aW9ucyBiZXR3ZWVuIGV4cGVyaWVuY2VkIGRldmVsb3BlcnMgYWJvdXQgQ0JPUiwgcGFydGlj dWxhcmx5IGRldmVsb3BlcnMgb2YgZGl2ZXJzZSBiYWNrZ3JvdW5kcyBidXQgd2hvIGFyZSBleHBl cmllbmNlZCBpbiBkYXRhIHNlcmlhbGl6YXRpb24gYW5kIGtub3dsZWRnZSByZXByZXNlbnRhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5vdGF0aW9uIGNoYW5nZXMgSeKAmXZlIHN1 Z2dlc3RlZCBmb3IgbWFqb3IgdHlwZXMgYXJlIE5PVCBmb3IgdGhlIGJlbmVmaXQgb2YgYSBuZXdj b21lciByZWFkaW5nIHRoZSBkb2N1bWVudCwgeWV0IG9idmlvdXNseSB0aGV5IFNIT1VMRCBOT1Qg Y29uZnVzZSBhIG5ld2NvbWVyLCBub3Igc2hvdWxkIHRoZXkgc2VlbSBhIGJpZyBkZWFsIHRvIGFu eW9uZSBmYW1pbGlhciB3aXRoIENCT1IgdGhyb3VnaCBSRkMgNzA0OS4mbmJzcDsmbmJzcDsNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gZXhhbXBsZSBvZiBjb25mdXNp bmcgYmFzZWQgb24gY3VycmVudCB0ZXJtaW5vbG9neTombmJzcDsgaW4gYW4gZS1tYWlsIGV4Y2hh bmdlIHdpdGggYW4gZXhwZXJpZW5jZWQgQ0JPUiBpbXBsZW1lbnRvciwgaGUgc2FpZCBzb21ldGhp bmcgdGhhdCBkaWRu4oCZdCBtYWtlIHNlbnNlIHRvIG1lOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkhvd2V2ZXIsIGtlZXAgaW4gbWluZCB0aGF0IGl0IGRvZXNu J3QgbWF0dGVyIHdoZXRoZXIgSlNPTiBoYXMgYSB0ZXh0IHN0cmluZyB0eXBlIG9yIG5vdCAtIHRo ZSBxdWVzdGlvbiBoZXJlIGlzIHdoZXRoZXIgaXQgaXMgcGVybWlzc2libGUgdG8gY29udmVydCBK U09OIHN0cmluZ3MgaW50byBDQk9SIGJpbmFyeSBzdHJpbmdzLCBhbmQgdGhlIGFuc3dlcg0KIGlz IG9idmlvdXNseSB0aGF0IGl0IGlzIHBlcm1pc3NpYmxlLCBhdCBsZWFzdCBieSBJRVRGIHN0YW5k YXJkcy4gPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5XaXRob3V0IG5hbWluZyBoaW0sIEkgcmVzcGVjdCB0aGUgYXV0aG9y4oCZcyBp bnRlbnQgaW4gc2F5aW5nIGl0LCBidXQgSSBjYW7igJl0IGFncmVlIGluIGRldGFpbC4mbmJzcDsg Jm5ic3A7Jm5ic3A7SGVyZeKAmXMgbXkgbG9naWMgZm9yIHdhbnRpbmcgQ0JPUi1CSVMgdG8gdW5h bWJpZ3VvdXNseSBtYWtlIGhpcyBzdGF0ZW1lbnQgZmFsc2U6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkpTT04g dGV4dCBpcyBlbmNvZGVkIGFzIFVURi04IChkZWZhdWx0KSwgVVRGLTE2IG9yIFVURi0zMi4gJm5i c3A7Jm5ic3A7KFJGQyA3MTU5LCBzZWN0aW9uIDguMSwgY2xhcmlmaWVkIGluIFJGQyA4MjU5IHNl Y3Rpb24gOC4xKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5KU09OIHN0cmluZ3Mg YXJlIGNvbXBvc2VkIGVudGlyZWx5IG9mIFVuaWNvZGUgY2hhcmFjdGVycyAoUkZDIDgyNTkgc2Vj dGlvbiA4LjIpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkNCT1IgbWFqb3IgdHlw ZSAyIGlzIGZvciBieXRlcywgd2l0aG91dCBhbnkgaW1wbGllZCBlbmNvZGluZy4gKFJGQyA3MDQ5 LCBzZWN0aW9uIDIuMS4pPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkNCT1IgbWFq b3IgdHlwZSAzIGlzIGZvciBVTklDT0RFIHRleHQgZW5jb2RlZCBhcyBVVEYtOC4gKFJGQyA3MDQ5 LCBzZWN0aW9uIDIuMS4pPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkNCT1IgdHJl YXRzIEpTT04gdGV4dCBpcyBhIHNlcXVlbmNlIG9mIGNoYXJhY3RlcnMsIG5vdCBlbmNvZGVkIGJ5 dGVzIChSRkMgNzA0OSwgc2VjdGlvbiA0LCBjb25maXJtaW5nICMyIGFib3ZlLik8bzpwPjwvbzpw PjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SUVURiBzdGFuZGFyZHMgYXJlIGdlbmVyYWxseSB2ZXJ5 IHNwZWNpZmljIGFib3V0IHRoaW5ncyBsaWtlIGNoYXJhY3RlciBlbmNvZGluZ3MuJm5ic3A7IFll dCBhbiBleHBlcmllbmNlZCBDQk9SIGRldmVsb3BlciBpcyB0ZWxsaW5nIG1lIGl04oCZcyBwZXJm ZWN0bHkgT0sgdG8gbG9zZSB0aGUgY2hhcmFjdGVyIGVuY29kaW5nIGluZm9ybWF0aW9uIGJ5IGNv bnZlcnRpbmcgSlNPTiBzdHJpbmdzIGFzIENCT1IgYmluYXJ5IHN0cmluZ3MuJm5ic3A7Jm5ic3A7 DQogKE5vdyBpZiB0aGUgQ0JPUiBiaW5hcnkgc3RyaW5nIHdlcmUgcHJlY2VkZWQgYnkgYSB0YWcg KG1ham9yIHR5cGUgNikgaW5kaWNhdGluZyBhIHNwZWNpZmljIGNoYXJhY3RlciBlbmNvZGluZywg c3VjaCBhcyBJU08vSUVDIDg4NTktMToxOTk4LCBJIGNvdWxkIGFjY2VwdCB0aGUgYXJndW1lbnQs IGJ1dCB3ZSBkb27igJl0IGhhdmUgc3VjaCBzdHJpbmcgZW5jb2RpbmcgdGFncyBzcGVjaWZpZWQg eWV0LikmbmJzcDsmbmJzcDsgSXQgbWF5IHNlZW0gYSBzbWFsbCBwb2ludA0KIHRvIGEgcGVyc29u IHdvcmtpbmcgaW4gc29tZSBzcGVjaWZpYyBwcm9ncmFtbWluZyBsYW5ndWFnZSwgYnV0IHdoZW4g aW50ZXJuYXRpb25hbCBhbmQgcG9seWdsb3QgY29uY2VybnMgYXJlIHRha2VuIGludG8gZWZmZWN0 LCBsb29zaW5nIGNoYXJhY3RlciBlbmNvZGluZyBpbmZvcm1hdGlvbiBpcyBhIHZlcnkgYmFkIHRo aW5nLCBidXQgSSB0aGluayBoZSBvdmVyZ2VuZXJhbGl6ZWQgYmVjYXVzZSBvZiBoaXMgbGFuZ3Vh Z2UgYmFja2dyb3VuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgYWZ0ZXIgc3Vic3RhbnRp YWwgcmVmbGVjdGlvbiwgSSB1bmRlcnN0YW5kIHdoeSB0aGUgb3JpZ2luYWwgYXV0aG9yIHNhaWQg d2hhdCBoZSBkaWQ6IGhlIHdhcyB0aGlua2luZyBpbiB0ZXJtcyBvZiBhIHZlbmVyYWJsZSBvbGQg bGFuZ3VhZ2U6IFBlcmwgNS4mbmJzcDsmbmJzcDsgKFBlcmwgaXMgc28gb2xkLCBpdCBwcmVkYXRl cyBVbmljb2RlLikmbmJzcDsmbmJzcDsgVGhlIHByb2JsZW0gaW4gUGVybCBpcyB0aGVyZSBhcmUg bm8gbmF0aXZlDQogYmluYXJ5IChieXRlcykgdHlwZSwgYnV0IGl04oCZcyBhIGNvbW1vbiBwcmFj dGljZSB0byBzdG9yZSBiaW5hcnkgZGF0YSBpbiDigJxzdHJpbmdz4oCdLiZuYnNwOyZuYnNwOyBU aGUgUGVybCBsYW5ndWFnZSBDQk9SLVhTIHBhY2thZ2Ugb2ZmZXJzIGEgY29uZmlndXJhYmxlIG9w dGlvbiBvbiBob3cgdG8gZW5jb2RlIFBlcmwgc3RyaW5ncyBpbiBDQk9SLCBhbmQgdGhlIGRlZmF1 bHQgc2V0dGluZyB0byBlbmNvZGluZyBQZXJsIHN0cmluZ3MgYXMgMiByYXRoZXIgdGhhbiAzLiZu YnNwOyZuYnNwOw0KIFRvIGEgUGVybCBwcm9ncmFtbWVyLCBzdHJpbmdzIGFyZSBhIHBsYWNlIHRv IHN0b3JlIGVpdGhlci4mbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBzb3J0IG9mIGNvbmZ1c2lvbiB3 b3VsZCBiZSByZWR1Y2VkIGJ5IGVsaW1pbmF0aW5nIOKAnHN0cmluZ+KAnSBmcm9tIHRoZSBuYW1l cyBvZiB0aGUgbWFqb3IgdHlwZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZvciBub24t QVNDSUkgY2FzZXMsIGNoYXJhY3RlciBlbmNvZGluZyBtYXR0ZXJzLCBidXQgb2Z0ZW4gb3Zlcmxv b2tlZCBpbiBzaW1wbGUgZXhhbXBsZXMuJm5ic3A7IEkgdGhpbmsgdGhlIGV1cm8gY3VycmVuY3kg c2lnbiAoSlNPTiDigJxcdTIwYTDigJ0pIGlzIGEgZ29vZCBleGFtcGxlLiZuYnNwOyZuYnNwOyBJ dCBTSE9VTEQgYmUgZW5jb2RlZCBhcyBDQk9SIGhleCA2MyBFMiA4MiBBMCwgYmVjYXVzZSBVJiM0 MzsyMEEwIGlzIGluIFVURi04IEUyDQogODIgQTAuIEl0IFNIT1VMRCBOT1QgYmUgZW5jb2RlZCBh cyBDQk9SIGhleCA2MSA4MCwgbm9yIDQxIDgwLCBldmVuIHRob3VnaCBoZXggODAgaGFzIGJlZW4g YXNzaWduZWQgdG8gdGhlIGV1cm8gY3VycmVuY3kgc2lnbiBpcyBoZXggODAgaW4gYSBjb21tb25s eSB1c2VkIGNvZGUgcGFnZS4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGUg4oCcTWFw4oCdIHRlcm0gZm9yIG1ham9yIHR5cGUgNSBpcyBjYW4gYmUgc2ltaWxh cmx5IGZpbGxlZCB3aXRoIGNvbmZsaWN0aW5nIG51YW5jZSBhY3Jvc3MgYSBwb2x5Z2xvdCBjb21t dW5pdHkuJm5ic3A7Jm5ic3A7Jm5ic3A7IFNvbWUgcHJvZ3JhbW1pbmcgZW52aXJvbm1lbnRzIGhh dmUgYSB2ZXJ5IHNwZWNpZmljIGludGVycHJldGF0aW9uIG9mIE1hcCB3aGljaCBtYXkgbm90IG1h dGNoIHRob3NlIG9mIENCT1IuJm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlLA0KIG1vZGVybiBFQ01B U2NyaXB0IHNwZWNpZmljYXRpb25zIGFuZCBKYXZhU2NyaXB0IGltcGxlbWVudGF0aW9ucyBoYXZl IGEgbmF0aXZlIE1hcCB0eXBlIHRoYXQgKGxpa2UgQ0JPUikgc3VwcG9ydHMgbm9uLXByaW1pdGl2 ZSBrZXlzIChsaWtlIGFuIGFycmF5KS4mbmJzcDsmbmJzcDsgUHJvYmxlbSBoZXJlIGlzIHRoYXQg YnV0IHVubGlrZSBSRkMgNzA0OSwgYSBKYXZhU2NyaXB0IE1hcCBkb2VzIG5vdCBhdHRlbXB0IHRv IGRlZmluZSB2YWx1ZS1lcXVhbGl0eSBvZiBzdWNoDQogbm9uLXByaW1pdGl2ZSBrZXlzLCBzZXR0 aW5nIGluc3RlYWQgZm9yIG9iamVjdCBpZGVudGl0eSBlcXVhbGl0eS4mbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRlcm1pbm9sb2d5IHdpc2UsIHNlbGVj dGluZyBhIHBsYXRmb3JtLW5ldXRyYWwgdGVybSB3aXRoIG1pbmltYWwgaW1wbGllZCBtZWFuaW5n IGZvciB0aGUgZXhpc3Rpbmcgc2VtYW50aWNzIG9mIG1lc3NhZ2UgNSwgJm5ic3A7SSBzdGlsbCBz dWdnZXN0IOKAnFBBSVJT4oCdIGlzIGJldHRlciB0aGFuIOKAnE1hcOKAnSBmb3IgdGhlIHNhbWUg cmVhc29uIEnigJlkIGxpa2UgdG8gdXNlIOKAnEJZVEVT4oCdIGluc3RlYWQgb2Yg4oCcYnl0ZSBz dHJpbmfigJ0uDQogJm5ic3A7VGhlIGxleGljYWwgY29udmVudGlvbiBvZiB3cml0aW5nIGVhY2gg bWFqb3IgdHlwZSBudW1lcmljIHZhbHVlIHdpdGggYm90aCBhIG51bWJlciBhbmQgbW5lbW9uaWMg aXMgdG8gZnVydGhlciBkaXN0aW5ndWlzaCB0aGUgd29yZHMgbGlrZSBVTklDT0RFIGluIHRleHQg ZnJvbSB1c2FnZSBhcyBhIG1ham9yIHR5cGUuJm5ic3A7Jm5ic3A7Jm5ic3A7IFRodXMgY29tYmlu aW5nIG90aGVyIGZlZWRiYWNrLCBJ4oCZbGwgdXBkYXRlIG15IHN1Z2dlc3Rpb25zIHRvOiZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAwL1VOU0lHTkVEPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS9ORUdBVElWRTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDIvQllURVM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzL1VOSUNPREU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA0L0lURU1TPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNS9QQUlSUzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDYv VEFHPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNy9PVEhFUjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGlzOiBhKSBhdm9pZHMgYWJicmV2aWF0aW9ucyBpbiB0aGUgYWJicmV2aWF0aW9ucyBpbiBt bmVtb25pY3MsIGFuZCBiKSB1c2VzIHByb3BlciBzaW5ndWxhci9wbHVyYWwgY2FzaW5nLiZuYnNw OyAmbmJzcDtJ4oCZbSBub3QgcGFydGljdWxhcmx5IGhhcHB5IHdpdGggNC9JVEVNUywgYW5kIG9u bHkgdXBkYXRlZCBpdCBmcm9tIDQvU0VRIHRvIGFkZHJlc3MgdGhlIGNvbnNpc3RlbmN5IHBvaW50 LCBhbnlvbmUgaGF2ZSBhIGJldHRlcg0KIGlkZWE/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_MWHPR22MB092614EF622E8B051E2DC3D792680MWHPR22MB0926namp_-- From nobody Fri May 25 21:59:09 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD85C1242F5 for ; Fri, 25 May 2018 21:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-G2kL6COfMw for ; Fri, 25 May 2018 21:59:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729511200C1 for ; Fri, 25 May 2018 21:59:03 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 25 May 2018 21:56:13 -0700 From: Jim Schaad To: 'Burt Harris' , 'Carsten Bormann' , References: In-Reply-To: Date: Fri, 25 May 2018 21:58:52 -0700 Message-ID: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01D3F473.940CCE80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHmzlBe2cO3RfutfAx4r0Nk9O25LKQbu6Xg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 04:59:08 -0000 ------=_NextPart_000_0003_01D3F473.940CCE80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: CBOR On Behalf Of Burt Harris Sent: Friday, May 25, 2018 7:09 PM To: Carsten Bormann ; cbor@ietf.org Subject: [Cbor] Consistent translations between JSON and CBOR =20 Let=E2=80=99s discuss clarifying the JSON interop goals in CBOR-BIS. = =20 Carson raised some good points earlier, saying certain decisions had = been made for consistency with JSON, and I see the value in that. We = should, enhance section 4 of RFC 7049 dealing with this (it is = currently non-normative), and the latest draft-ietf-cbor-7049bis section = 5 hasn=E2=80=99t changed that in a meaningful way. Both sections tackle = the relationship to JSON in an ad-hock way, making testing = implementations more difficult. I think we can improve on this in the = goals section of draft-ietf-cbor-7049bis as follows: =20 1. CBOR-BIS SHOULD include a normative specification for translating any = valid JSON text into CBOR, and back. =20 2. The JSON -> CBOR translator SHOULD be non-ambiguous. Any given = semantically meaningful JSON text should have exactly one = straightforward CBOR translation. (CBOR compression schemes can be = excluded.) =20 [JLS] I assume that this means that you do not care about trying to map = binary items from base64 to binary fields which is one of the major = reasons that I can see for encoding JSON as CBOR. Of course doing so = without a schema is problematic. =20 3. A CBOR -> JSON translator for supported JSON types MAY involve some = ambiguity. However a JSON -> CBOR -> JSON translation SHOULD introduce = minimal text changes, allowing for limited following = semantically-equivalent changes: a. Non-significant whitespace outside of JSON strings MAY change. = E. g. [ 0, 1, 2 ] could have whitespace modified to become [0,1,2]. = (pretty printing lost or gained) =20 b. Backslash-encoded character in quoted JSON strings MAY change = to/from UTF-8 equivalents. The euro currency symbol in [ "=E2=82=A0" ] = could be changed to an escape sequence [ "\u20a0" ], or vice versa. =20 [JLS] Do you care about the translation being syntactically the same or = semantically the same. Items b-e all come out in the was if all you care = about is semantics. =20 c. Unquoted JSON number MAY change in value-preserving ways. E. g. input = of [1.0] might could become [1] in the round-tripped JSON. Quoted = numeric strings SHOULD NOT be changed, so ["1.0"] should stay unaltered. =20 d. Invalid Unicode characters in JSON, weather quoted and escaped or = not, may be replaced with something else, or even generate an error. = (See unpaired surrogates below if you want more information.) =20 e. Unquoted non-negative numeric keys in an map MAY be sorted in = ascending order and moved the front of the list of key/value pairs. = E.g. {1: "one", 3: "three", 2: "two"} might become {1: "one", 2: = "two", 3: "three" }. =20 4. The CBOR <-> JSON round-trip options (a, b, c and d above) MAY be = selected by translator options, or (in the future) represented by some = CBOR tag scheme to further improve the preservation of JSON text = representation. =20 CBOR compression schemes are not =E2=80=9Cstraightforward=E2=80=9D and = thus are excluded from #2 above, but they should still always round-trip = from and to JSON as required by the other goals. =20 =20 Preserving order of keys in round-trip translation =20 Limiting the JSON text changes in a round-trip scenario as specified = above may be particularly useful us humans. Consider the case where a = file exists both in CBOR format and JSON, where the JSON exists so that = it can be dealt with by humans and version control systems like git: =20 A human author may have a good reason to put entries in a JSON object in = a particular order, for example putting the most = =E2=80=9Cimportant=E2=80=9D fields up front. Most tools, including = tools that (edit JSON in some automated way) won=E2=80=99t re-order the = keys without good reason, and that helps the changes recorded in the = version control system remain minimal. =20 =20 [JLS] Would you consider using a hash table for keys for efficiency to = be a good reason? Anybody relying on this outside of an absolute = latest browser is probably hoping w/o reason. It is not something that = I would ever think about relying on. =20 But I=E2=80=99ve worked with some tools that do (unintentionally) = reorder keys in a JSON object, its generally considered a bug by the = users even though RFC 8259 formally says: =20 An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. =20 Such bugs have largely become a non-issue for tools written in = JavaScript, as all modern implementations preserve the order of fields = in an object, with one notable exception: keys which are non-negative = numbers always sort to the top. I suspect the reason for the = exception in JavaScript runtimes is exactly the same as that mentioned = in draft-ietf-cbor-7049bis section 4.7: numeric keys are often used in = cases where order is important, perhaps to normalization or performance. =20 Perhaps this helps explain my earlier thoughts that the default = (untagged) definition of CBOR major type 5 should be treated as = order-preserving at a syntax level, or perhaps even better adopt the = latest ECMAscript=E2=80=99s spec=E2=80=99s description of the = key-ordering behavior of objects as an alternative to the RFC 7049 = concept of normalization. =20 =20 Resource Constrained Systems =20 On a highly resource constrained system, encoding CBOR object with some = specific (or consistent) ordering of fields is an advantage. These = systems will typically not use hash tables to store data. And the most = resource constrained systems may opt for numeric keys as an = optimization, and could treat any keys that aren=E2=80=99t encoded with = major type 0 as low-priority or irrelevant details, and might be able to = quickly skip to the end of the map without recording the keys or values. = =20 =20 [JLS] You need to look at what you believe the constraint is before you = make this statement. If the constraint is transmission time/power then = the highest priority is the smallest possible encoding so that using = positive and negative numbers as well as one byte text strings or binary = strings because what you care about rather than sorting all of the = integer values first. =20 Unpaired UTF-16 surrogates (advanced topic) =20 JSON has a gray area. RFC 8259 section 8.2 points out an ambiguity in = JSON semantics to the JSON string "\uDEAD", The JSON RFC says = =E2=80=9CThe behavior of software that receives JSON texts containing = such values is unpredictable.=E2=80=9D But under the formal syntax = (ABNF) of the JSON it is not explicitly forbidden. Skip here to end = if your brain is overloaded by that concept. =20 This backslash-prefixed sequence is technically the JSON representation = of a UTF-16 surrogate. It is a gray area because it DOES NOT represent = a valid UNICODE character, there is no UTF-8 encoding it, per RFC 3629. = Thus I limit the preservation of JSON rule in (3)(e) above. But there = are a few thing we could do:=20 =20 1. Default option: Treat JSON strings representing unpaired surrogates = as an error, since JSON doesn=E2=80=99t define a meaning, even though = they are syntactically allowed. This is what the CBOR Playground = (http://cbor.me) does, and IMHO it is a perfectly reasonable option. = The error message given by the playground for "\uDEAD" is = =E2=80=9CExpected one of [89abAB], [0-7] at line 1, column 5 (byte 5) = after "\uD=E2=80=9D, which seems technically correct. =20 2. Replace any unknown, unrecognizable or unrepresentable character, = with U+FFFD =EF=BF=BD REPLACEMENT CHARACTER. (This loose some = information but it is non-fatal, but it is exactly what the REPLACMENT = CHARACTER code point is meant for.) =20 3. Leverage certain parts of this JSON grey-zone to define ways to = encode CBOR datatypes not normally found in JSON. For example, we COULD = define a special interpretation of a JSON string starting with "\uDB64" = to mean the following text is actually Base 64 encoded binary data, = leveraging to RFC 3548! A "\uDB16" prefix COULD mean Base 16 = (hexadecimal) encoded binary. There are literally thousands of = unpaired surrogates that are possible to give meaning to in a = =E2=80=9CCBOR in JSON=E2=80=9D context. While not as mnemonic as = CBOR=E2=80=99s diagnostic notation, this approach might give a way to = translate any valid CBOR into syntactically correct JSON, and back! =20 4. Preserve unpaired surrogates, perhaps by defining a CBOR tag for = labeling Wobbly Transformation Format (WTF-8.) [Not a good idea, WTF-8 = is not meant for information interchange, but I include it for = completeness.] =20 [JLS] Or look at section 4.2 and not really worry about it as both = formats currently support it. =20 Finally, the data may be invalid, such as invalid UTF-8 strings or date strings that do not conform to [RFC3339 ].=20 =20 ------=_NextPart_000_0003_01D3F473.940CCE80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: CBOR = <cbor-bounces@ietf.org> On Behalf Of Burt = Harris
Sent: Friday, May 25, 2018 7:09 PM
To: = Carsten Bormann <cabo@tzi.org>; cbor@ietf.org
Subject: = [Cbor] Consistent translations between JSON and = CBOR

 

Let=E2=80=99s discuss clarifying the JSON interop = goals in CBOR-BIS.     

 

Carson = raised some good points earlier, saying certain decisions had been made = for consistency with JSON, and I see the value in that.   We = should,  enhance section 4 of RFC 7049 dealing with this (it is = currently non-normative), and the latest draft-ietf-cbor-7049bis section = 5 hasn=E2=80=99t changed that in a meaningful way.  Both sections = tackle the relationship to JSON in an ad-hock way, making testing = implementations more difficult.   I think we can improve on = this in the goals section of draft-ietf-cbor-7049bis as = follows:

 

  1. CBOR-BIS SHOULD = include a normative specification for translating any valid JSON text = into CBOR, and back.

 

  1. The JSON -> CBOR = translator SHOULD be non-ambiguous.   Any given semantically = meaningful JSON text should have exactly one straightforward CBOR = translation.  (CBOR compression schemes can be = excluded.)

 

[JLS]=C2=A0 = I assume that this means that you do not care about trying to map binary = items from base64 to binary fields which is one of the major reasons = that I can see for encoding JSON as CBOR.=C2=A0 Of course doing so = without a schema is problematic.

 

  1. A CBOR -> JSON translator for supported JSON types MAY involve = some ambiguity.  However a JSON -> CBOR -> JSON translation = SHOULD introduce minimal text changes, allowing for limited following = semantically-equivalent changes:

a.       = Non-significant whitespace outside of JSON = strings MAY change.  E. g. [ 0, 1, 2 ] could have whitespace = modified to become [0,1,2].  (pretty printing lost or = gained)

 

    1. Backslash-encoded character in quoted JSON strings MAY =  change to/from UTF-8 equivalents.  The euro currency symbol = in [ "=E2=82=A0" ] could be changed to an escape sequence [ = "\u20a0" ], or vice versa.

 

[JLS] Do you = care about the translation being syntactically the same or semantically = the same. Items b-e all come out in the was if all you care about is = semantics.

 

    1. Unquoted JSON number MAY change in value-preserving ways. E. g. = input of [1.0] might could become [1] in the round-tripped JSON.  = Quoted numeric strings SHOULD NOT be changed, so ["1.0"] = should stay unaltered.

 

    1. Invalid Unicode characters in JSON, weather quoted and escaped or = not, may be replaced with something else, or even generate an = error.   (See unpaired surrogates below if you want more = information.)

 

    1. Unquoted non-negative numeric keys in an map MAY be sorted in = ascending order and moved the front of the list of key/value = pairs.   E.g.  {1: "one", 3: "three", =  2: "two"} might become {1: "one",  2: = "two", 3: "three" }.

 

  1. The CBOR <-> = JSON round-trip options (a, b, c and d above) MAY be selected by = translator options, or (in the future) represented by some CBOR tag = scheme to further improve the preservation of JSON text = representation.

 

CBOR = compression schemes are not =E2=80=9Cstraightforward=E2=80=9D and thus = are excluded from #2 above, but they should still always round-trip from = and to JSON as required by the other goals.   =

 

Preserving order of keys in round-trip = translation

 

Limiting the = JSON text changes in a round-trip scenario as specified above may be = particularly useful us humans.   Consider the case where a = file exists both in CBOR format and JSON, where the JSON exists so that = it can be dealt with by humans and version control systems like = git:

 

A human author may have a good reason to put entries = in a JSON object in a particular order, for example putting the most = =E2=80=9Cimportant=E2=80=9D fields up front.   Most tools, = including tools that (edit JSON in some automated way) won=E2=80=99t = re-order the keys without good reason, and that helps the changes = recorded in the version control system remain minimal.    =

 

[JLS] Would you consider using a hash table for keys = for efficiency to be a good reason? =C2=A0=C2=A0Anybody relying on this = outside of an absolute latest browser is probably hoping w/o = reason.=C2=A0 It is not something that I would ever think about relying = on.

 

But I=E2=80=99ve worked with some tools that do = (unintentionally) reorder keys in a JSON object, its generally = considered a bug by the users even though RFC 8259 formally = says:

 

An object is = an unordered collection of zero or more = name/value

pairs, where = a name is a string and a value is a string, = number,

boolean, = null, object, or array.

 

Such bugs = have largely become a non-issue for tools written in JavaScript, as all = modern implementations preserve the order of fields in an object, with = one notable exception:   keys which are non-negative numbers = always sort to the top.    I suspect the reason for the = exception in JavaScript runtimes is exactly the same as that mentioned = in draft-ietf-cbor-7049bis section 4.7: numeric keys are often used in = cases where order is important, perhaps to normalization or = performance.

 

Perhaps this helps explain my earlier thoughts that = the default (untagged) definition of CBOR major type 5 should be treated = as order-preserving at a syntax level, or perhaps even better adopt the = latest ECMAscript=E2=80=99s spec=E2=80=99s description of the = key-ordering behavior of objects as an alternative to the RFC 7049 = concept of normalization.  

 

Resource = Constrained Systems

 

On a highly = resource constrained system, encoding CBOR object with some specific (or = consistent) ordering of fields is an advantage.   These = systems will typically not use hash tables to store data.   = And the most resource constrained systems may opt for numeric keys as an = optimization, and could treat any keys that aren=E2=80=99t = encoded with major type 0 as low-priority or irrelevant details, and = might be able to quickly skip to the end of the map without recording = the keys or values.  

 

[JLS] You = need to look at what you believe the constraint is before you make this = statement.=C2=A0 If the constraint is transmission time/power then the = highest priority is the smallest possible encoding so that using = positive and negative numbers as well as one byte text strings or binary = strings because what you care about rather than sorting all of the = integer values first.

 

Unpaired = UTF-16 surrogates (advanced topic)

 

JSON has a = gray area.   RFC 8259 section 8.2 points out an ambiguity in = JSON semantics to the JSON string "\uDEAD&= quot;, The JSON RFC says =E2=80=9CThe behavior of software = that receives JSON texts containing such values is = unpredictable.=E2=80=9D  But under the formal syntax (ABNF) = of the JSON it is not explicitly forbidden.    Skip = here to end if your brain is overloaded by that = concept.

 

This backslash-prefixed sequence is technically the = JSON representation of a UTF-16 surrogate.  It is a gray area = because it DOES NOT represent a valid UNICODE character, there is no = UTF-8 encoding it, per RFC 3629.   Thus I limit the = preservation of JSON rule in (3)(e) above.   But there are a = few thing we could do:

 

  1. Default option:  Treat JSON strings representing unpaired = surrogates as an error, since JSON doesn=E2=80=99t define a meaning, = even though they are syntactically allowed. This is what the CBOR = Playground (http://cbor.me) does, and = IMHO it is a perfectly reasonable option.  The error message given = by the playground for "\uDEAD" is =E2=80=9CExpected one of = [89abAB], [0-7] at line 1, column 5 (byte 5) after "\uD=E2=80=9D, = which seems technically correct.

 

  1. Replace any unknown, unrecognizable or = unrepresentable character, with U+FFFD =EF=BF=BD REPLACEMENT = CHARACTER.  (This loose some information but it is non-fatal, but = it  is exactly what the REPLACMENT CHARACTER code point is meant = for.)

 

  1. Leverage certain parts of this JSON = grey-zone to define ways to encode CBOR datatypes not normally found in = JSON.  For example, we COULD define a special interpretation of a = JSON string starting with "\uDB64" to mean the following text = is actually Base 64 encoded binary data, leveraging to RFC 3548!  A = "\uDB16" prefix COULD mean Base 16 (hexadecimal) encoded = binary.   There are literally thousands of unpaired surrogates = that are possible to give meaning to in a =E2=80=9CCBOR in JSON=E2=80=9D = context.  While not as mnemonic as CBOR=E2=80=99s diagnostic = notation, this approach might give a way to translate any valid CBOR = into syntactically correct JSON, and back!

 

  1. Preserve unpaired surrogates, perhaps = by defining a CBOR tag for labeling W= obbly Transformation Format  (WTF-8.)  [Not a good = idea, WTF-8 is not meant for information interchange, but I include it = for completeness.]

 

[JLS] Or look at = section 4.2 and not really worry about it as both formats currently = support it.

 

Finally, the data =
may be invalid, such as
=C2=A0=C2=A0 invalid UTF-8 =
strings or date strings that do not conform =
to
=C2=A0=C2=A0 [RFC3339]. =

 

------=_NextPart_000_0003_01D3F473.940CCE80-- From nobody Sat May 26 02:06:10 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FC5124B18 for ; Sat, 26 May 2018 02:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzX5QZlaUkbe for ; Sat, 26 May 2018 02:06:05 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003059.outbound.protection.outlook.com [40.92.3.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DD41242F7 for ; Sat, 26 May 2018 02:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bnKq2rZ1ljSQd0MX1MNNzy3LcRVdJNZ5ra/R6St2uQo=; b=fO9yhmxXDxpbm4jx1YMBaUDxvLJZtztKzXCgWjlFQgEETPA9ZBTVJEh0yfjUAS1Qw61YPUnxl4Z5UMabnK2EL30q8kR3FcD2gCa5AEW0rXDLN9sR0mBUq56PXNiee1nE+xYly52ICuNDhLcFtaBuCzo8qJVWfk59QSskj0YmKpzmJj+YxdHW9xLNAYtZ3TcxuvhnHWkjc9wqPV3K/glstPeuPfYusbv4gq+x491NuyakV/5Jcb4k4jiI1TD+9O58GWn3SA59xoUQywftZJ3tOQmQxIbP01n0r/v1PcgMf+YaAxIeCUCX0zDRIpOG4ikCTLg+xcikbtGEURtJKg1l4Q== Received: from BL2NAM02FT060.eop-nam02.prod.protection.outlook.com (10.152.76.53) by BL2NAM02HT084.eop-nam02.prod.protection.outlook.com (10.152.77.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.755.15; Sat, 26 May 2018 09:06:03 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com (10.152.76.53) by BL2NAM02FT060.mail.protection.outlook.com (10.152.76.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.820.8 via Frontend Transport; Sat, 26 May 2018 09:06:03 +0000 Received: from MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e]) by MWHPR22MB0926.namprd22.prod.outlook.com ([fe80::a17d:26b8:5557:8b8e%17]) with mapi id 15.20.0797.011; Sat, 26 May 2018 09:06:02 +0000 From: Burt Harris To: Jim Schaad , 'Carsten Bormann' , "cbor@ietf.org" Thread-Topic: [Cbor] Consistent translations between JSON and CBOR Thread-Index: AdP0gF5N5vVwj5IZRmKPMZ109U5YegALd9cAAAGs8WA= Date: Sat, 26 May 2018 09:06:02 +0000 Message-ID: References: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> In-Reply-To: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:FD31C8F6C96589EA4CAE18B3E0A5D09D9AC45F04302187D1748A9A0779357F26; UpperCasedChecksum:755E433AD31E2E789C5B5E1BC84BBA3793F6A3FB2D1ABB5293818F2AC6E3A0AE; SizeAsReceived:7136; Count:45 x-tmn: [aU90IG4UzPGx5qGFlt77nWH0/RjuEa8v] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2NAM02HT084; 7:HqEyrAxppomOQ577rOIZdbPmtOMECx+2UQ8EdvWc2nI/Cgf1a3TBWq7+OfGT9VSSzreTJwG0cL151eCllFkuxV52ZLZFKs5/ke0qhwvz4wsr+OeE20nzn3ulPEQq7QvC8G1jlTZUfnykn6UB4UZcklSwBbDmbV3BMY0EW7GWIDrRzc0ncApVqSvzlOEZPqvDbcVX3R3NX/2R907wMwZtwLZsgfN59YAV3Tt1Dn8taRaMfyWhYaAVhwXqe3Su1CY4 x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:(258095267146985); BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125466)(1603101448)(1701031045); SRVR:BL2NAM02HT084; x-ms-traffictypediagnostic: BL2NAM02HT084: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BL2NAM02HT084; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT084; x-forefront-prvs: 0684F80A5C x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(606006)(86362001)(76176011)(104016004)(82202002)(6506007)(6436002)(229853002)(73972006)(20460500001)(110136005)(59450400001)(6306002)(97736004)(6246003)(68736007)(99286004)(54896002)(55016002)(3660700001)(790700001)(7696005)(9686003)(102836004)(8936002)(2900100001)(236005)(345774005)(87572001)(8676002)(6346003)(25786009)(83332001)(5250100002)(81156014)(446003)(11346002)(26005)(476003)(2501003)(486006)(5660300001)(3280700002)(106356001)(33656002)(14454004)(105586002)(74316002)(561944003)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT084; H:MWHPR22MB0926.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: HP906IMjot5dYUjyYT7me1o7iqXgwSaoOa1ABdDW7cz1ovdMSmaeJX3RhUK1yzWz/uAoCwenWYCgQ8uNKBGw2OUenM9m3pacqBw1hjFa0RjxWAIPGhzHTQhtQ7b0+s1wek1fQgJ9BzFWK6GldFBBpxAtldDMVxnTo3r/L7BSj22U/mBjqB2DRyGz4z4S7vB8 Content-Type: multipart/alternative; boundary="_000_MWHPR22MB09269A48CA2EDB990B15006692680MWHPR22MB0926namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 09ef83d7-39f3-4807-0d07-08d5c2e7e7f9 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: 09ef83d7-39f3-4807-0d07-08d5c2e7e7f9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2018 09:06:02.7104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT084 Archived-At: Subject: Re: [Cbor] Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 09:06:09 -0000 --_000_MWHPR22MB09269A48CA2EDB990B15006692680MWHPR22MB0926namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmltLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suICAgRGV0YWlsZWQgcmVwbGllcyBi ZWxvdyB5b3VyIHF1b3RlcyBmb2xsb3cuDQoNCltKTFNdICBJIGFzc3VtZSB0aGF0IHRoaXMgbWVh bnMgdGhhdCB5b3UgZG8gbm90IGNhcmUgYWJvdXQgdHJ5aW5nIHRvIG1hcCBiaW5hcnkgaXRlbXMg ZnJvbSBiYXNlNjQgdG8gYmluYXJ5IGZpZWxkcyB3aGljaCBpcyBvbmUgb2YgdGhlIG1ham9yIHJl YXNvbnMgdGhhdCBJIGNhbiBzZWUgZm9yIGVuY29kaW5nIEpTT04gYXMgQ0JPUi4gIE9mIGNvdXJz ZSBkb2luZyBzbyB3aXRob3V0IGEgc2NoZW1hIGlzIHByb2JsZW1hdGljLg0KDQpQbGVhc2UgZG9u 4oCZdCBhc3N1bWUgdGhhdCwgd2VyZSBpbiBhZ3JlZW1lbnQgdGhlcmUgaXMgYSBwcm9ibGVtIGFy b3VuZCBiaW5hcnkgZGF0YSBpbiBKU09OIGluIG5lZWQgb2YgYSBzb2x1dGlvbi4gICBUaGUgcHJv YmxlbXMgSSB0aGluayBpbXBsaWVkIGluIHlvdXIgcmVzcG9uc2UgaXMgdGhhdCB0aGF0IHRoZXJl IGlzIG5vIGJhc2lzIHRvZGF5IGZvciBhc3N1bWluZyB0aGF0IEpTT04gc3RyaW5ncyBhcmUgaW4g ZmFjdCBiaW5hcnkgZGF0YSBlbmNvZGVkIGluIGJhc2U2NC4gICBJIGd1ZXNzIHlvdSBtYXkgdGFs a2luZyBpbiB0ZXJtcyBvZiBhbiBhc3N1bXB0aW9uIHRoYXQgYSBKU09OIHN0cmluZyBtYXkgYmUg YmFzZTY0IGJ5IG1hdGNoaW5nIHNvbWUgcGF0dGVybiwgYnV0IEkgYXNzZXJ0IHRoYXQgYSBwYXR0 ZXJuIG1hdGNoIG9mIG5vcm1hbCBVbmljb2RlIGNoYXJhY3RlcnMgYWxvbmUgaXMgbm90IGEgZ29v ZCByZWFzb24gdG8gZW5jb2RlIHRoYXQgc3RyaW5nIHVzaW5nIENCT1IgbWFqb3IgdHlwZSAyIGlu c3RlYWQgb2YgMy4gICBBbiBlc2NhcGUgbWVjaGFuaXNtIG9mIHNvbWUgc29ydCBzaG91bGQgYmUg cmVxdWlyZWQuDQoNClRoaXMgcHJvYmxlbSBjb21lcyB1cCBiZWNhdXNlIEpTT04gKGxpa2UgZWFy bHkgSmF2YVNjcmlwdCkgc2ltcGx5IHB1bnRlZCBvbiBiaW5hcnkgZGF0YSwgYnV0IG1vZGVybiBK YXZhU2NyaXB0IGltcGxlbWVudGF0aW9ucyBoYXZlIHRhY2tsZWQgdGhlIHByb2JsZW0gd2l0aCBK YXZhU2NyaXB0IHR5cGVkIGFycmF5cywgbGlrZSBVSW50OEFycmF5LiAgICBVbmZvcnR1bmF0ZWx5 LCBKU09OIHdhc27igJl0IHdyaXR0ZW4gd2l0aCB0aGUgZmxleGliaWxpdHkgdG8gZGVhbCB3aXRo IGFuIGV4cGFuZGFibGUgc2V0IG9mIHR5cGVzLCBpdCB3YXMgZGVzaWduZWQgdG8gYmUgYSBzdHJp Y3Qgc3Vic2V0IG9mIGVhcmx5IEphdmFTY3JpcHQsIHNvIG5hdGl2ZSBKU09OLnBhcnNlKClpbXBs ZW1lbnRhdGlvbnMgSSBrbm93IG9mIGRvIG5vdCByZXR1cm4gYSBVSW50OEFycmF5Lg0KDQpJIGRv IGNhcmUgYWJvdXQgcmVwcmVzZW50aW5nIGJpbmFyeSBkYXRhIGNvbXBhY3RseSB3aGlsZSBwcmVz ZXJ2aW5nIHJvdW5kIHRyaXBwaW5nIHdpdGhvdXQgc2NoZW1hLCBhbmQgaW4gdGhhdCBzcGlyaXQg bWFrZSB0aGUgcHJvcG9zYWwgbGF0ZXIgaW4gbXkgbWVzc2FnZSB0byBhZGRyZXNzIGV4YWN0bHkg dGhhdCBzY2VuYXJpbywgdXNpbmcgdGhlIGFkbWl0dGVkbHkgb2JzY3VyZSBjYXNlIG9mIGFuIFx1 IGVzY2FwZWQgdW5wYWlyZWQgc3Vycm9nYXRlIGNvZGVwb2ludHMgaW4gSlNPTiwgaW4gcGxhY2Ug b2YgcmVxdWlyaW5nIHNjaGVtYSBrbm93bGVkZ2Ugb3IgcGF0dGVybiBtYXRjaGluZyBhc3N1bXB0 aW9ucy4gICBKU09OIHN5bnRheCBydWxlcyBzdXBwb3J0IHRoaXMgY29ybmVyIGNhc2UsIGJ1dCBp dCBpcyBzZW1hbnRpY2FsbHkgdW5kZWZpbmVkIGluIEpTT04gZHVlIHRvIHJlc3RyaWN0aW9ucyBp biBVVEYtOC4gICBUaGlzIG1ha2VzIHRoaXMgZm9ybSBvZiB1bnBhaXJlZCBzdXJyb2dhdGUgZmVy dGlsZSBncm91bmQgZm9yIG91dC1vZi10aGUtYm94IHRoaW5raW5nLCBhbmQgYWxsb3dzIGEgbnVt YmVyIG9mIGVzY2FwZSBtZWNoYW5pc21zIGZvciBiYXNlMTYsIGJhc2UzMiwgYmFzZSA2NCwgYW5k IHBvdGVudGlhbGx5IG90aGVyIGVuY29kaW5ncyBpZiBuZWVkZWQsIGFsbCB3aXRob3V0IGludGVy ZmVyaW5nIHdpdGggYW55IHZhbGlkIFVOSUNPREUgY2hhcmFjdGVycy4NCg0KW0pMU10gRG8geW91 IGNhcmUgYWJvdXQgdGhlIHRyYW5zbGF0aW9uIGJlaW5nIHN5bnRhY3RpY2FsbHkgdGhlIHNhbWUg b3Igc2VtYW50aWNhbGx5IHRoZSBzYW1lLiBJdGVtcyBiLWUgYWxsIGNvbWUgb3V0IGluIHRoZSB3 YXMgaWYgYWxsIHlvdSBjYXJlIGFib3V0IGlzIHNlbWFudGljcy4NCg0KQm90aCwgdG8gdGhlIGV4 dGVudCByZWFzb25hYmx5IHBvc3NpYmxlLiAgIEkgdGhpbmsgcHJlc2VydmluZyBKU09OIHNlbWFu dGljcyBzZWVtcyBsaWtlIGEgTVVTVCwgYW5kIHByZXNlcnZpbmcgSlNPTiBzeW50YXggIGlzIGEg U0hPVUxEIG9yIGF0IGxlYXN0IGEgTUFZLCBnaXZlbiBhbiB3ZWxsIHRob3VnaHQgb3V0IGRlZmlu aXRpb24gb2Ygd2hhdCBpcyByZWFzb25hYmx5IHBvc3NpYmxlLg0KDQpUaGUgbnVtYmVyZWQgcGFy YWdyYXBocyAzIGEtLWUgYXJlIG15IGJlc3QgYXR0ZW1wdCB0byBkYXRlIHRvIGRlZmluZSBhIGZv cm1hbCBzZXQgb2YgSlNPTiBzeW50YXggcHJlc2VydmF0aW9ucyBleGNlcHRpb25zIHRoYXQgY292 ZXIgd2hhdCBpcyByZWFzb25hYmx5IHBvc3NpYmxlIGluIGEgcm91bmQtdHJpcCBmcm9tIEpTT04g dG8gYSBtb3JlIGNvbXBhY3QgQ0JPUiBmb3JtYXQgYW5kIGJhY2ssIHdpdGhvdXQgaW50cm9kdWNp bmcgYWRkaXRpb25hbCBDQk9SIHRhZ3MgZm9yIHRoZSBwdXJwb3NlLg0KDQpUb29scyBsaWtlIHZl cnNpb24gY29udHJvbCwgY29tcGFyZSB1dGlsaXRpZXMsIGVkaXRvcnMsIGV0Yy4gc2ltcGx5IGRv buKAmXQga25vdyBhYm91dCBKU09OIHNlbWFudGljcywgdGhleSBzaW1wbHkgdHJlYXQgSlNPTiBh cyB0ZXh0LCBvciBqdXN0IGEgcmF3IHNlcXVlbmNlIG9mIGJ5dGVzLiAgIEV2ZW4gdG9vbHMgdGhh dCB1bmRlcnN0YW5kIEpTT04gc2VtYW50aWNzIHRlbmQgdG8gcHJlc2VydmUgc3ludGF4IHdoZXJl IHBvc3NpYmxlLCB0aG91Z2ggdGhlcmUgYXJlIG9idmlvdXNseSBjb3VudGVyLWV4YW1wbGVzLiAg IEEgZ29vZCBleGFtcGxlIG1pZ2h0IGJlIHRoZSBOUE0gdG9vbCBpbiB0aGUgTm9kZUpTIGVjb3N5 c3RlbS4gICBSZWNlbnQgdmVyc2lvbnMgbWF5IGNoYW5nZSB0aGUgcGFja2FnZS5qc29uIGZpbGUg aW4gdGhlIHdvcmtpbmcgZGlyZWN0b3J5LCBidXQgaW4gZ2VuZXJhbCBpdCBhdm9pZHMgcmVvcmRl cmluZyB0aGUga2V5cywgZGVzcGl0ZSB0aGUgZmFjdCBrZXkgb3JkZXIgaXMgc2VtYW50aWNhbGx5 IGlycmVsZXZhbnQuICAgSG93ZXZlciwgcmVjZW50IHVzZSBvZiB0aGF0IHRvb2wgaGFzIGludHJv ZHVjZWQgc3ludGFjdGljIGNoYW5nZXMgbGlrZSByZW1vdmluZyBhIGxpbmUgYnJha2UgYmV0d2Vl biB0aGUgYnJhY2VzIG9mIGEgZW1wdHkgb2JqZWN0LCBvciBwcmV0dHkgcHJpbnRpbmcgYW4gYXJy YXkgd2l0aCBjb25zaXN0ZW50IGluZGVudGF0aW9uLiAgICBJ4oCZdmUgdXNlZCBzdWNoIGJlaGF2 aW9yIGFzIGEgZGF0YXBvaW50IGluIGNvbnNpZGVyaW5nIHdoYXQgaXMgcmVhc29uYWJseSBwb3Nz aWJsZSBpbiB0ZXJtcyBvZiBwcmVzZXJ2aW5nIHN5bnRheC4NCg0KW0pMU10gV291bGQgeW91IGNv bnNpZGVyIHVzaW5nIGEgaGFzaCB0YWJsZSBmb3Iga2V5cyBmb3IgZWZmaWNpZW5jeSB0byBiZSBh IGdvb2QgcmVhc29uPyAgIEFueWJvZHkgcmVseWluZyBvbiB0aGlzIG91dHNpZGUgb2YgYW4gYWJz b2x1dGUgbGF0ZXN0IGJyb3dzZXIgaXMgcHJvYmFibHkgaG9waW5nIHcvbyByZWFzb24uICBJdCBp cyBub3Qgc29tZXRoaW5nIHRoYXQgSSB3b3VsZCBldmVyIHRoaW5rIGFib3V0IHJlbHlpbmcgb24u DQoNCkkgdW5kZXJzdGFuZCB0aGUgcXVlc3Rpb24sIGJ1dCBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg dGhlIHN0YXRlbWVudHMgdGhhdCBmb2xsb3cuICAgWWVzLCBJIGhhdmUgdGhvdWdodCBhYm91dCBo YXNoIHRhYmxlcywgYW5kIEkgY29uY2x1ZGUgdGhpbmsgdGhlaXIgZWZmaWNhY2llcyBhcmUgZ29v ZCByZWFzb24gaW4gYSByb3VuZC10cmlwIGNvbnZlcnNpb24gc2NlbmFyaW8uICAgSSBzdWdnZXN0 IHRoZXJlIGlzIHRoZXJlIGlzIG5vIGludHJpbnNpYyBhZHZhbnRhZ2Ugb2YgYSBoYXNoIHRhYmxl IGluIHRoYXQgc2NlbmFyaW8sIGJlY2F1c2UgaXQgZG9lcyBub3QgY2FsbCBmb3IgcmFuZG9tIGFj Y2Vzcy4gICBUaGVyZSBjYW4gYmUgcGVyZm9ybWFuY2UgYmVuZWZpdHMgb2YgaGFzaCB0YWJsZXMs IGJ1dCB0aGV5ICBvbmx5IG9jY3VyIHVuZGVyIHNwZWNpZmljIGNpcmN1bXN0YW5jZXMuDQoNCkZv ciBtYW55IGlmIG5vdCBtb3N0IHNjZW5hcmlvcyBvbiBzeXN0ZW1zIHdpdGggY2FjaGUgbWVtb3Jp ZXMsIG9yZGVyIGRpY3Rpb25hcmllcyBvdXRwZXJmb3JtIGhhc2ggdGFibGVzIGZvciBzbWFsbCBu dW1iZXJzIG9mIGVudHJpZXMuICAgTGV2ZXJhZ2luZyB0aGlzIG9ic2VydmF0aW9uIGlzIGFzc29j aWF0ZWQgd2l0aCBKSVQgY29tcGlsZWQgSmF2YVNjcmlwdCBhbmQgdGhlIOKAnGhpZGRlbi1jbGFz c+KAnSBvcHRpbWl6YXRpb24sIGFuZCB0aGF0IGNoYW5nZSBpcyBub3QgYSBuZXcgdGhpbmcuICBJ biBDaHJvbWUgYW5kIHRoZSBWOCBlbmdpbmUgZm9yIGV4YW1wbGUgSSBiZWxpZXZlIGl0IGRhdGVz IGJhY2sgdG8gdGhlIGZpcnN0IHJlbGVhc2UgaW4gMjAwOC4gICAgSW4gTm9kZS5qcyB0aGUga2V5 IGFzc3VtcHRpb25zIEkgbWFkZSBkYXRlIGFsbCB0aGUgd2F5IGJhY2sgdG8gdjAuOS4xMC4gICBZ b3UgIGNhbiB1c2UgdGhlIGZvbGxvd2luZyBKYXZhU2NyaXB0IGV4cHJlc3Npb24gYXQgYSBjb25z b2xlIHRvIHRlc3Q6DQoNCiAgICAgSlNPTi5zdHJpbmdpZnkoeyBiZXRhOiAxLCBhbHBoYTogMiwg MzozLCAxOjEgfSkNCg0KTXkgZXhwZWN0ZWQgcmVzdWx0Og0KDQoneyIxIjoxLCIzIjozLCJiZXRh IjoxLCJhbHBoYSI6Mn0nDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGZpbmQgb3RoZXIgcGxh dGZvcm1zIHRoYXQgcHJvZHVjZSBhIGRpZmZlcmVudCBKU09OIHJlc3VsdC4gICBPYnZpb3VzbHkg cmVhbGx5IG9sZCBicm93c2VycyBtYXkgZ2VuZXJhdGUgYW4gZXJyb3IsIGJlY2F1c2UgbmF0aXZl IHN1cHBvcnQgZm9yIEpTT04gaXNu4oCZdCBvbiB0aGUgcmVhbGx5IG9sZCBvbmVzLCBidXQgdGhl IGxhdGVzdCBicm93c2VyIG1hcmtldCBzaGFyZSBmaWd1cmVzIHN1Z2dlc3QgdGhlcmUgYXJlbuKA mXQgbWFueSBwZW9wbGUgYXQgYWxsIHJ1bm5pbmcgYW5jaWVudCBicm93c2VycywgQ2hyb21lIGlz IGNsZWFybHkgdGhlIG1hcmtldCBsZWFkZXIuICAgKGh0dHBzOi8veW91cmJyb3dzZXIuaXMvYnJv d3Nlci1tYXJrZXQtc2hhcmUvMjAxOC8wNS8pDQoNCltKTFNdIFlvdSBuZWVkIHRvIGxvb2sgYXQg d2hhdCB5b3UgYmVsaWV2ZSB0aGUgY29uc3RyYWludCBpcyBiZWZvcmUgeW91IG1ha2UgdGhpcyBz dGF0ZW1lbnQuICBJZiB0aGUgY29uc3RyYWludCBpcyB0cmFuc21pc3Npb24gdGltZS9wb3dlciB0 aGVuIHRoZSBoaWdoZXN0IHByaW9yaXR5IGlzIHRoZSBzbWFsbGVzdCBwb3NzaWJsZSBlbmNvZGlu ZyBzbyB0aGF0IHVzaW5nIHBvc2l0aXZlIGFuZCBuZWdhdGl2ZSBudW1iZXJzIGFzIHdlbGwgYXMg b25lIGJ5dGUgdGV4dCBzdHJpbmdzIG9yIGJpbmFyeSBzdHJpbmdzIGJlY2F1c2Ugd2hhdCB5b3Ug Y2FyZSBhYm91dCByYXRoZXIgdGhhbiBzb3J0aW5nIGFsbCBvZiB0aGUgaW50ZWdlciB2YWx1ZXMg Zmlyc3QuDQoNCkdvb2QgcG9pbnQsIGJ1dCBpZiB0cmFuc21pc3Npb24gYmFuZHdpZHRoIChub3Qg Y29tcHV0ZSBwb3dlciBvciBtZW1vcnkpIGlzIHdoYXQgeW91IGFyZSBvcHRpbWl6aW5nIHRvIG1p bmltaXplLCBzb21lIGZvcm0gb2YgQ0JPUiBjb21wcmVzc2lvbiB3aWxsIHByb2JhYmx5IHdpbiBv dXQsIGFuZCBJIHNwZWNpZmljYWxseSBleGNsdWRlZCBjb21wcmVzc2lvbiBpbiB0aGlzIHRocmVh ZCAoYnV0IHBsYW4gdG8gYWRkcmVzcyBpdCBzb29uLikNCg0KSW9UIGRldmljZXMgYXJlIGFscmVh ZHkgcXVpdGUgaW5leHBlbnNpdmUsIGJ1dCBjb3N0cyBzdGlsbCBtYXR0ZXIuICAgSW4gdGhlIG1v c3QgY29zdC1zZW5zaXRpdmUgYXBwbGljYXRpb25zLCB0aGUgZXhwZW5zZSBvZiBhIHdpcmVsZXNz IHJhZGlvIG1heSBiZSBzaWduaWZpY2FudCBpZiB3aXJlZCBhIGNvbm5lY3Rpb24gaXMgYXZhaWxh YmxlLiAgIFdpcmVkIGNvbm5lY3Rpb25zIHdpbGwgcmVtYWluIGNvbXBldGl0aXZlIGluIHNvbWUg bWFya2V0cy4gICBUb2RheSBmb3IgZXhhbXBsZSBpdCBpcyBwb3NzaWJsZSB0byBidXkgYSBTb0Mg d2l0aCB3aXJlZCAoSTJDKSBwcm9jZXNzb3IgYW5kIEkyQyBidXMgcmVwZWF0ZXJzIGNoZWFwZXIg dGhhbiBCTEUgcmFkaW8sIGFuZCByZWxpYWJseSBnZXQgbG9uZ2VyIGRpc3RhbmNlcy4gICBSUy00 MjIvNDg1LCAgQ0FOIHdpbGwgcHJvYmFibHkgcmVtYWluIGEgZ29vZCBvcHRpb24gZm9yIGV2ZW4g bG9uZ2VyIGhhdWwgd2lyZXMgaW4gdmFyaW91cyBzY2VuYXJpb3MsIGJ1dCBhdCBhIGhpZ2hlciBj b3N0IHRoYW4gcm9jay1ib3R0b20gSTJDLg0KDQpBcyBhbiBleGFtcGxlIG9mIHdoYXQgSSB0aGlu ayBvZiBhcyBhIGhpZ2hseSBjb25zdHJhaW5lZCBzeXN0ZW0gdG9kYXksIGNvbnNpZGVyIGEgUFNP QyA0IChDWThDNDAxM1NYSS00MDA8aHR0cDovL3d3dy5jeXByZXNzLmNvbS9wYXJ0L2N5OGM0MDEz c3hpLTQwMD4pLCB3aXRoIGEgMTZNSHogQVJNIENvcmV0ZXgtTTAgYW5kIEkyQyBhdCB1cCB0byAx IG1lZ2FiaXQvc2VjOyBhbmQgd2l0aCBhIGJ1ZGdldGFyeSBwcmljZSBpbiAyMDE4IHVuZGVyICQx L3VuaXQuICAgIFRoZSBjb25zdHJhaW50cyBvbiB0aGF0IG1vZGVsIGFyZSB0aGF0IGl0IGhhcyBv bmx5IDUgR1BJT3MgKGluY2x1ZGluZyAyIGZvciB0aGUgSTJDKSwgOEtCIG9mIGZsYXNoLCBhbmQg MktCIG9mIFJBTS4gICAgVGhhdOKAmXMgd2F5IG1vcmUgYmFuZHdpZHRoIGFuZCBNSVBTIHRoYW4g dGhlIGZpcnN0IG1pbmljb21wdXRlcnMgSSB3b3JrZWQgb24gYWxtb3N0IDQwIHllYXJzIGFnbywg YnV0IG5vIG1vcmUgbWVtb3J5Lg0KDQpbSkxTXSBPciBsb29rIGF0IHNlY3Rpb24gNC4yIGFuZCBu b3QgcmVhbGx5IHdvcnJ5IGFib3V0IGl0IGFzIGJvdGggZm9ybWF0cyBjdXJyZW50bHkgc3VwcG9y dCBpdC4NCg0KUGVyaGFwcyB5b3UgY2FuIGNsYXJpZnkgdGhpcyBsYXN0IHBvaW50LiAgIEnigJl2 ZSBsb29rZWQgYXQgc2VjdGlvbiA0LjIgaW4gYSBudW1iZXIgb2YgZG9jdW1lbnQsIEnigJltIG5v dCBzdXJlIGRvY3VtZW50IHlvdSBtZWFuLg0KDQo= --_000_MWHPR22MB09269A48CA2EDB990B15006692680MWHPR22MB0926namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1vbm9zcGFjZWQNCgl7bXNv LXN0eWxlLW5hbWU6bW9ub3NwYWNlZDt9DQpzcGFuLnNtYWxsY2Fwcw0KCXttc28tc3R5bGUtbmFt ZTpzbWFsbGNhcHM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjE0OTAxMDAxNzI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE2MTc1MzU2NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjI4OTI4MzI4Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTg3NjUzMTU0IDIxMTQ2MzkxMzAgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDouNzVpbjsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suJm5ic3A7Jm5i c3A7IERldGFpbGVkIHJlcGxpZXMgYmVsb3cgeW91ciBxdW90ZXMgZm9sbG93LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5bSkxTXTwvYj4mbmJzcDsgSSBhc3N1bWUgdGhhdCB0aGlzIG1lYW5z IHRoYXQgeW91IGRvIG5vdCBjYXJlIGFib3V0IHRyeWluZyB0byBtYXAgYmluYXJ5IGl0ZW1zIGZy b20gYmFzZTY0IHRvIGJpbmFyeSBmaWVsZHMgd2hpY2ggaXMgb25lIG9mIHRoZSBtYWpvciByZWFz b25zIHRoYXQgSSBjYW4gc2VlIGZvciBlbmNvZGluZyBKU09OIGFzIENCT1IuJm5ic3A7IE9mIGNv dXJzZSBkb2luZyBzbyB3aXRob3V0IGEgc2NoZW1hIGlzDQogcHJvYmxlbWF0aWMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBkb27igJl0IGFzc3VtZSB0aGF0LCB3ZXJlIGluIGFncmVl bWVudCB0aGVyZSBpcyBhIHByb2JsZW0gYXJvdW5kIGJpbmFyeSBkYXRhIGluIEpTT04gaW4gbmVl ZCBvZiBhIHNvbHV0aW9uLiZuYnNwOyZuYnNwOyBUaGUgcHJvYmxlbXMgSSB0aGluayBpbXBsaWVk IGluIHlvdXIgcmVzcG9uc2UgaXMgdGhhdCB0aGF0IHRoZXJlIGlzIG5vIGJhc2lzIHRvZGF5IGZv ciBhc3N1bWluZyB0aGF0IEpTT04gc3RyaW5ncyBhcmUgaW4NCiBmYWN0IGJpbmFyeSBkYXRhIGVu Y29kZWQgaW4gYmFzZTY0LiZuYnNwOyAmbmJzcDtJIGd1ZXNzIHlvdSBtYXkgdGFsa2luZyBpbiB0 ZXJtcyBvZiBhbiBhc3N1bXB0aW9uIHRoYXQgYSBKU09OIHN0cmluZyBtYXkgYmUgYmFzZTY0IGJ5 IG1hdGNoaW5nIHNvbWUgcGF0dGVybiwgYnV0IEkgYXNzZXJ0IHRoYXQgYSBwYXR0ZXJuIG1hdGNo IG9mIG5vcm1hbCBVbmljb2RlIGNoYXJhY3RlcnMgYWxvbmUgaXMgbm90IGEgZ29vZCByZWFzb24g dG8gZW5jb2RlIHRoYXQgc3RyaW5nDQogdXNpbmcgQ0JPUiBtYWpvciB0eXBlIDIgaW5zdGVhZCBv ZiAzLiZuYnNwOyZuYnNwOyBBbiBlc2NhcGUgbWVjaGFuaXNtIG9mIHNvbWUgc29ydCBzaG91bGQg YmUgcmVxdWlyZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgcHJvYmxlbSBjb21lcyB1 cCBiZWNhdXNlIEpTT04gKGxpa2UgZWFybHkgSmF2YVNjcmlwdCkgc2ltcGx5IHB1bnRlZCBvbiBi aW5hcnkgZGF0YSwgYnV0IG1vZGVybiBKYXZhU2NyaXB0IGltcGxlbWVudGF0aW9ucyBoYXZlIHRh Y2tsZWQgdGhlIHByb2JsZW0gd2l0aCBKYXZhU2NyaXB0IHR5cGVkIGFycmF5cywgbGlrZSBVSW50 OEFycmF5LiZuYnNwOyZuYnNwOyAmbmJzcDtVbmZvcnR1bmF0ZWx5LCBKU09OIHdhc27igJl0IHdy aXR0ZW4NCiB3aXRoIHRoZSBmbGV4aWJpbGl0eSB0byBkZWFsIHdpdGggYW4gZXhwYW5kYWJsZSBz ZXQgb2YgdHlwZXMsIGl0IHdhcyBkZXNpZ25lZCB0byBiZSBhIHN0cmljdCBzdWJzZXQgb2YgZWFy bHkgSmF2YVNjcmlwdCwgc28gbmF0aXZlDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkpTT04ucGFyc2UoKTwvc3Bhbj5pbXBsZW1lbnRhdGlvbnMgSSBr bm93IG9mIGRvIG5vdCByZXR1cm4gYSBVSW50OEFycmF5LiZuYnNwOyZuYnNwOyZuYnNwOw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgPGk+ZG88L2k+IGNhcmUgYWJvdXQgcmVwcmVzZW50aW5n IGJpbmFyeSBkYXRhIGNvbXBhY3RseSB3aGlsZSBwcmVzZXJ2aW5nIHJvdW5kIHRyaXBwaW5nIHdp dGhvdXQgc2NoZW1hLCBhbmQgaW4gdGhhdCBzcGlyaXQgbWFrZSB0aGUgcHJvcG9zYWwgbGF0ZXIg aW4gbXkgbWVzc2FnZSB0byBhZGRyZXNzIGV4YWN0bHkgdGhhdCBzY2VuYXJpbywgdXNpbmcgdGhl IGFkbWl0dGVkbHkgb2JzY3VyZSBjYXNlIG9mIGFuDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlx1PC9zcGFuPiBlc2NhcGVkIHVucGFpcmVkIHN1cnJv Z2F0ZSBjb2RlcG9pbnRzIGluIEpTT04sIGluIHBsYWNlIG9mIHJlcXVpcmluZyBzY2hlbWEga25v d2xlZGdlIG9yIHBhdHRlcm4gbWF0Y2hpbmcgYXNzdW1wdGlvbnMuJm5ic3A7Jm5ic3A7IEpTT04g c3ludGF4IHJ1bGVzIHN1cHBvcnQgdGhpcyBjb3JuZXIgY2FzZSwgYnV0IGl0IGlzIHNlbWFudGlj YWxseSB1bmRlZmluZWQgaW4gSlNPTiBkdWUNCiB0byByZXN0cmljdGlvbnMgaW4gVVRGLTguJm5i c3A7Jm5ic3A7IFRoaXMgbWFrZXMgdGhpcyBmb3JtIG9mIHVucGFpcmVkIHN1cnJvZ2F0ZSBmZXJ0 aWxlIGdyb3VuZCBmb3Igb3V0LW9mLXRoZS1ib3ggdGhpbmtpbmcsIGFuZCBhbGxvd3MgYSBudW1i ZXIgb2YgZXNjYXBlIG1lY2hhbmlzbXMgZm9yIGJhc2UxNiwgYmFzZTMyLCBiYXNlIDY0LCBhbmQg cG90ZW50aWFsbHkgb3RoZXIgZW5jb2RpbmdzIGlmIG5lZWRlZCwgYWxsIHdpdGhvdXQgaW50ZXJm ZXJpbmcgd2l0aA0KIGFueSB2YWxpZCBVTklDT0RFIGNoYXJhY3RlcnMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPltKTFNdPC9iPiBEbyB5b3UgY2FyZSBhYm91dCB0aGUgdHJhbnNsYXRpb24g YmVpbmcgc3ludGFjdGljYWxseSB0aGUgc2FtZSBvciBzZW1hbnRpY2FsbHkgdGhlIHNhbWUuIEl0 ZW1zIGItZSBhbGwgY29tZSBvdXQgaW4gdGhlIHdhcyBpZiBhbGwgeW91IGNhcmUgYWJvdXQgaXMg c2VtYW50aWNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb3RoLCB0byB0aGUgZXh0ZW50IDxp PnJlYXNvbmFibHk8L2k+IHBvc3NpYmxlLiZuYnNwOyZuYnNwOyBJIHRoaW5rIHByZXNlcnZpbmcg SlNPTiBzZW1hbnRpY3Mgc2VlbXMgbGlrZSBhIE1VU1QsIGFuZCBwcmVzZXJ2aW5nIEpTT04gc3lu dGF4ICZuYnNwO2lzIGEgU0hPVUxEIG9yIGF0IGxlYXN0IGEgTUFZLCBnaXZlbiBhbiB3ZWxsIHRo b3VnaHQgb3V0IGRlZmluaXRpb24gb2Ygd2hhdCBpcyByZWFzb25hYmx5IHBvc3NpYmxlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbnVtYmVyZWQgcGFyYWdyYXBocyAzIGEtLWUgYXJlIG15 IGJlc3QgYXR0ZW1wdCB0byBkYXRlIHRvIGRlZmluZSBhIGZvcm1hbCBzZXQgb2YgSlNPTiBzeW50 YXggcHJlc2VydmF0aW9ucyBleGNlcHRpb25zIHRoYXQgY292ZXIgd2hhdCBpcw0KPGk+cmVhc29u YWJseTwvaT4gcG9zc2libGUgaW4gYSByb3VuZC10cmlwIGZyb20gSlNPTiB0byBhIG1vcmUgY29t cGFjdCBDQk9SIGZvcm1hdCBhbmQgYmFjaywgd2l0aG91dCBpbnRyb2R1Y2luZyBhZGRpdGlvbmFs IENCT1IgdGFncyBmb3IgdGhlIHB1cnBvc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvb2xz IGxpa2UgdmVyc2lvbiBjb250cm9sLCBjb21wYXJlIHV0aWxpdGllcywgZWRpdG9ycywgZXRjLiBz aW1wbHkgZG9u4oCZdCBrbm93IGFib3V0IEpTT04gc2VtYW50aWNzLCB0aGV5IHNpbXBseSB0cmVh dCBKU09OIGFzIHRleHQsIG9yIGp1c3QgYSByYXcgc2VxdWVuY2Ugb2YgYnl0ZXMuJm5ic3A7Jm5i c3A7IEV2ZW4gdG9vbHMgdGhhdCB1bmRlcnN0YW5kIEpTT04gc2VtYW50aWNzIHRlbmQgdG8gcHJl c2VydmUgc3ludGF4IHdoZXJlDQogcG9zc2libGUsIHRob3VnaCB0aGVyZSBhcmUgb2J2aW91c2x5 IGNvdW50ZXItZXhhbXBsZXMuJm5ic3A7Jm5ic3A7IEEgZ29vZCBleGFtcGxlIG1pZ2h0IGJlIHRo ZSBOUE0gdG9vbCBpbiB0aGUgTm9kZUpTIGVjb3N5c3RlbS4mbmJzcDsmbmJzcDsgUmVjZW50IHZl cnNpb25zIG1heSBjaGFuZ2UgdGhlIHBhY2thZ2UuanNvbiBmaWxlIGluIHRoZSB3b3JraW5nIGRp cmVjdG9yeSwgYnV0IGluIGdlbmVyYWwgaXQgYXZvaWRzIHJlb3JkZXJpbmcgdGhlIGtleXMsIGRl c3BpdGUgdGhlIGZhY3QNCiBrZXkgb3JkZXIgaXMgc2VtYW50aWNhbGx5IGlycmVsZXZhbnQuJm5i c3A7Jm5ic3A7IEhvd2V2ZXIsIHJlY2VudCB1c2Ugb2YgdGhhdCB0b29sIGhhcyBpbnRyb2R1Y2Vk IHN5bnRhY3RpYyBjaGFuZ2VzIGxpa2UgcmVtb3ZpbmcgYSBsaW5lIGJyYWtlIGJldHdlZW4gdGhl IGJyYWNlcyBvZiBhIGVtcHR5IG9iamVjdCwgb3IgcHJldHR5IHByaW50aW5nIGFuIGFycmF5IHdp dGggY29uc2lzdGVudCBpbmRlbnRhdGlvbi4mbmJzcDsmbmJzcDsmbmJzcDsgSeKAmXZlIHVzZWQg c3VjaCBiZWhhdmlvciBhcw0KIGEgZGF0YXBvaW50IGluIGNvbnNpZGVyaW5nIHdoYXQgaXMgcmVh c29uYWJseSBwb3NzaWJsZSBpbiB0ZXJtcyBvZiBwcmVzZXJ2aW5nIHN5bnRheC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+W0pMU108L2I+IFdvdWxkIHlvdSBjb25zaWRlciB1c2luZyBhIGhh c2ggdGFibGUgZm9yIGtleXMgZm9yIGVmZmljaWVuY3kgdG8gYmUgYSBnb29kIHJlYXNvbj8gJm5i c3A7Jm5ic3A7QW55Ym9keSByZWx5aW5nIG9uIHRoaXMgb3V0c2lkZSBvZiBhbiBhYnNvbHV0ZSBs YXRlc3QgYnJvd3NlciBpcyBwcm9iYWJseSBob3Bpbmcgdy9vIHJlYXNvbi4mbmJzcDsgSXQgaXMg bm90IHNvbWV0aGluZyB0aGF0IEkgd291bGQgZXZlciB0aGluaw0KIGFib3V0IHJlbHlpbmcgb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdW5kZXJzdGFuZCB0aGUgcXVlc3Rpb24sIGJ1dCBu b3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHN0YXRlbWVudHMgdGhhdCBmb2xsb3cuJm5ic3A7Jm5i c3A7IFllcywgSSBoYXZlIHRob3VnaHQgYWJvdXQgaGFzaCB0YWJsZXMsIGFuZCBJIGNvbmNsdWRl IHRoaW5rIHRoZWlyIGVmZmljYWNpZXMgYXJlIGdvb2QgcmVhc29uIGluIGEgcm91bmQtdHJpcCBj b252ZXJzaW9uIHNjZW5hcmlvLiZuYnNwOyAmbmJzcDtJIHN1Z2dlc3QgdGhlcmUgaXMgdGhlcmUN CiBpcyBubyBpbnRyaW5zaWMgYWR2YW50YWdlIG9mIGEgaGFzaCB0YWJsZSBpbiB0aGF0IHNjZW5h cmlvLCBiZWNhdXNlIGl0IGRvZXMgbm90IGNhbGwgZm9yIHJhbmRvbSBhY2Nlc3MuJm5ic3A7Jm5i c3A7IFRoZXJlIGNhbiBiZSBwZXJmb3JtYW5jZSBiZW5lZml0cyBvZiBoYXNoIHRhYmxlcywgYnV0 IHRoZXkgJm5ic3A7b25seSBvY2N1ciB1bmRlciBzcGVjaWZpYyBjaXJjdW1zdGFuY2VzLiZuYnNw OyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBtYW55IGlmIG5vdCBtb3N0IHNj ZW5hcmlvcyBvbiBzeXN0ZW1zIHdpdGggY2FjaGUgbWVtb3JpZXMsIG9yZGVyIGRpY3Rpb25hcmll cyBvdXRwZXJmb3JtIGhhc2ggdGFibGVzIGZvciBzbWFsbCBudW1iZXJzIG9mIGVudHJpZXMuJm5i c3A7Jm5ic3A7IExldmVyYWdpbmcgdGhpcyBvYnNlcnZhdGlvbiBpcyBhc3NvY2lhdGVkIHdpdGgg SklUIGNvbXBpbGVkIEphdmFTY3JpcHQgYW5kIHRoZSDigJxoaWRkZW4tY2xhc3PigJ0gb3B0aW1p emF0aW9uLA0KIGFuZCB0aGF0IGNoYW5nZSBpcyBub3QgYSBuZXcgdGhpbmcuJm5ic3A7IEluIENo cm9tZSBhbmQgdGhlIFY4IGVuZ2luZSBmb3IgZXhhbXBsZSBJIGJlbGlldmUgaXQgZGF0ZXMgYmFj ayB0byB0aGUgZmlyc3QgcmVsZWFzZSBpbiAyMDA4LiZuYnNwOyZuYnNwOyAmbmJzcDtJbiBOb2Rl LmpzIHRoZSBrZXkgYXNzdW1wdGlvbnMgSSBtYWRlIGRhdGUgYWxsIHRoZSB3YXkgYmFjayB0byB2 MC45LjEwLiZuYnNwOyZuYnNwOyBZb3UgJm5ic3A7Y2FuIHVzZSB0aGUgZm9sbG93aW5nIEphdmFT Y3JpcHQgZXhwcmVzc2lvbg0KIGF0IGEgY29uc29sZSB0byB0ZXN0OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKU09OLnN0cmluZ2lmeSh7IGJldGE6IDEsIGFscGhh OiAyLCAzOjMsIDE6MSB9KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgZXhwZWN0 ZWQgcmVzdWx0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4neyZx dW90OzEmcXVvdDs6MSwmcXVvdDszJnF1b3Q7OjMsJnF1b3Q7YmV0YSZxdW90OzoxLCZxdW90O2Fs cGhhJnF1b3Q7OjJ9JzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGxldCBtZSBrbm93 IGlmIHlvdSBmaW5kIG90aGVyIHBsYXRmb3JtcyB0aGF0IHByb2R1Y2UgYSBkaWZmZXJlbnQgSlNP TiByZXN1bHQuJm5ic3A7Jm5ic3A7IE9idmlvdXNseSByZWFsbHkgb2xkIGJyb3dzZXJzIG1heSBn ZW5lcmF0ZSBhbiBlcnJvciwgYmVjYXVzZSBuYXRpdmUgc3VwcG9ydCBmb3IgSlNPTiBpc27igJl0 IG9uIHRoZSByZWFsbHkgb2xkIG9uZXMsIGJ1dCB0aGUgbGF0ZXN0IGJyb3dzZXIgbWFya2V0IHNo YXJlDQogZmlndXJlcyBzdWdnZXN0IHRoZXJlIGFyZW7igJl0IG1hbnkgcGVvcGxlIGF0IGFsbCBy dW5uaW5nIGFuY2llbnQgYnJvd3NlcnMsIENocm9tZSBpcyBjbGVhcmx5IHRoZSBtYXJrZXQgbGVh ZGVyLiZuYnNwOyZuYnNwOyAoPGEgaHJlZj0iaHR0cHM6Ly95b3VyYnJvd3Nlci5pcy9icm93c2Vy LW1hcmtldC1zaGFyZS8yMDE4LzA1LyI+aHR0cHM6Ly95b3VyYnJvd3Nlci5pcy9icm93c2VyLW1h cmtldC1zaGFyZS8yMDE4LzA1LzwvYT4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPltKTFNd PC9iPiBZb3UgbmVlZCB0byBsb29rIGF0IHdoYXQgeW91IGJlbGlldmUgdGhlIGNvbnN0cmFpbnQg aXMgYmVmb3JlIHlvdSBtYWtlIHRoaXMgc3RhdGVtZW50LiZuYnNwOyBJZiB0aGUgY29uc3RyYWlu dCBpcyB0cmFuc21pc3Npb24gdGltZS9wb3dlciB0aGVuIHRoZSBoaWdoZXN0IHByaW9yaXR5IGlz IHRoZSBzbWFsbGVzdCBwb3NzaWJsZSBlbmNvZGluZyBzbyB0aGF0IHVzaW5nIHBvc2l0aXZlIGFu ZCBuZWdhdGl2ZQ0KIG51bWJlcnMgYXMgd2VsbCBhcyBvbmUgYnl0ZSB0ZXh0IHN0cmluZ3Mgb3Ig YmluYXJ5IHN0cmluZ3MgYmVjYXVzZSB3aGF0IHlvdSBjYXJlIGFib3V0IHJhdGhlciB0aGFuIHNv cnRpbmcgYWxsIG9mIHRoZSBpbnRlZ2VyIHZhbHVlcyBmaXJzdC4mbmJzcDsmbmJzcDsNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIHBvaW50LCBidXQgaWYgdHJhbnNtaXNzaW9uIGJhbmR3 aWR0aCAobm90IGNvbXB1dGUgcG93ZXIgb3IgbWVtb3J5KSBpcyB3aGF0IHlvdSBhcmUgb3B0aW1p emluZyB0byBtaW5pbWl6ZSwgc29tZSBmb3JtIG9mIENCT1IgY29tcHJlc3Npb24gd2lsbCBwcm9i YWJseSB3aW4gb3V0LCBhbmQgSSBzcGVjaWZpY2FsbHkgZXhjbHVkZWQgY29tcHJlc3Npb24gaW4g dGhpcyB0aHJlYWQgKGJ1dCBwbGFuIHRvIGFkZHJlc3MNCiBpdCBzb29uLikgJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklvVCBkZXZpY2VzIGFyZSBhbHJlYWR5IHF1aXRlIGlu ZXhwZW5zaXZlLCBidXQgY29zdHMgc3RpbGwgbWF0dGVyLiZuYnNwOyZuYnNwOyBJbiB0aGUgbW9z dCBjb3N0LXNlbnNpdGl2ZSBhcHBsaWNhdGlvbnMsIHRoZSBleHBlbnNlIG9mIGEgd2lyZWxlc3Mg cmFkaW8gbWF5IGJlIHNpZ25pZmljYW50IGlmIHdpcmVkIGEgY29ubmVjdGlvbiBpcyBhdmFpbGFi bGUuJm5ic3A7Jm5ic3A7IFdpcmVkIGNvbm5lY3Rpb25zIHdpbGwgcmVtYWluIGNvbXBldGl0aXZl DQogaW4gc29tZSBtYXJrZXRzLiZuYnNwOyZuYnNwOyBUb2RheSBmb3IgZXhhbXBsZSBpdCBpcyBw b3NzaWJsZSB0byBidXkgYSBTb0Mgd2l0aCB3aXJlZCAoSTJDKSBwcm9jZXNzb3IgYW5kIEkyQyBi dXMgcmVwZWF0ZXJzIGNoZWFwZXIgdGhhbiBCTEUgcmFkaW8sIGFuZCByZWxpYWJseSBnZXQgbG9u Z2VyIGRpc3RhbmNlcy4mbmJzcDsmbmJzcDsgUlMtNDIyLzQ4NSwgJm5ic3A7Q0FOIHdpbGwgcHJv YmFibHkgcmVtYWluIGEgZ29vZCBvcHRpb24gZm9yIGV2ZW4gbG9uZ2VyIGhhdWwgd2lyZXMgaW4N CiB2YXJpb3VzIHNjZW5hcmlvcywgYnV0IGF0IGEgaGlnaGVyIGNvc3QgdGhhbiByb2NrLWJvdHRv bSBJMkMuJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B cyBhbiBleGFtcGxlIG9mIHdoYXQgSSB0aGluayBvZiBhcyBhIGhpZ2hseSBjb25zdHJhaW5lZCBz eXN0ZW0gdG9kYXksIGNvbnNpZGVyIGEgUFNPQyA0ICg8YSBocmVmPSJodHRwOi8vd3d3LmN5cHJl c3MuY29tL3BhcnQvY3k4YzQwMTNzeGktNDAwIj5DWThDNDAxM1NYSS00MDA8L2E+KSwgd2l0aCBh IDE2TUh6IEFSTSBDb3JldGV4LU0wIGFuZCBJMkMgYXQgdXAgdG8gMSBtZWdhYml0L3NlYzsgYW5k IHdpdGggYQ0KIGJ1ZGdldGFyeSBwcmljZSBpbiAyMDE4IHVuZGVyICQxL3VuaXQuJm5ic3A7Jm5i c3A7Jm5ic3A7IFRoZSBjb25zdHJhaW50cyBvbiB0aGF0IG1vZGVsIGFyZSB0aGF0IGl0IGhhcyBv bmx5IDUgR1BJT3MgKGluY2x1ZGluZyAyIGZvciB0aGUgSTJDKSwgOEtCIG9mIGZsYXNoLCBhbmQg MktCIG9mIFJBTS4mbmJzcDsmbmJzcDsmbmJzcDsgVGhhdOKAmXMgd2F5IG1vcmUgYmFuZHdpZHRo IGFuZCBNSVBTIHRoYW4gdGhlIGZpcnN0IG1pbmljb21wdXRlcnMgSSB3b3JrZWQgb24gYWxtb3N0 IDQwIHllYXJzIGFnbywNCiBidXQgbm8gbW9yZSBtZW1vcnkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPltKTFNdPC9iPiBPciBsb29rIGF0IHNlY3Rpb24gNC4yIGFuZCBub3QgcmVhbGx5IHdv cnJ5IGFib3V0IGl0IGFzIGJvdGggZm9ybWF0cyBjdXJyZW50bHkgc3VwcG9ydCBpdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyB5b3UgY2FuIGNsYXJpZnkgdGhpcyBsYXN0IHBvaW50 LiZuYnNwOyZuYnNwOyBJ4oCZdmUgbG9va2VkIGF0IHNlY3Rpb24gNC4yIGluIGEgbnVtYmVyIG9m IGRvY3VtZW50LCBJ4oCZbSBub3Qgc3VyZSBkb2N1bWVudCB5b3UgbWVhbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR22MB09269A48CA2EDB990B15006692680MWHPR22MB0926namp_-- From nobody Sat May 26 04:44:51 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AB12D945 for ; Sat, 26 May 2018 04:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAb18FIoacDU for ; Sat, 26 May 2018 04:44:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8261241FC for ; Sat, 26 May 2018 04:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4QBi7Z4013737; Sat, 26 May 2018 13:44:07 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40tLqq1FptzDWhB; Sat, 26 May 2018 13:44:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sat, 26 May 2018 13:44:06 +0200 Cc: Jim Schaad , "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 549027845.150311-16acdf81e7fa9fcd17766ad25b63050c Content-Transfer-Encoding: quoted-printable Message-Id: References: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> To: Burt Harris X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 11:44:51 -0000 On May 26, 2018, at 11:06, Burt Harris wrote: >=20 > Please don=E2=80=99t assume that, were in agreement there is a problem = around binary data in JSON in need of a solution. The problems I think = implied in your response is that that there is no basis today for = assuming that JSON strings are in fact binary data encoded in base64. = I guess you may talking in terms of an assumption that a JSON string may = be base64 by matching some pattern, but I assert that a pattern match of = normal Unicode characters alone is not a good reason to encode that = string using CBOR major type 2 instead of 3. An escape mechanism of = some sort should be required. CBOR was designed to enable =E2=80=9Cshrinking=E2=80=9D JSON text = strings into CBOR byte strings in those cases where the text strings = happen to match base64 or hex data. Tags 21 to 23 (Section 2.4.4.2) are = designed to be used on the CBOR side to indicate the binary data needs = to be transformed back to text strings, and how. These are single-byte = (1+0) tags because we expected them to be used frequently in = JSON-to-CBOR converters. Without schema information, simply trying to recognize base64 (or = base16) poses a danger that any other text string will look like it is = base64/16-encoded. E.g., =E2=80=9Cbeef=E2=80=9D and =E2=80=9Cunshrinkable= =E2=80=9D might turn into 23(h=E2=80=99beef=E2=80=99) and = 21(h=E2=80=99ba7b21ae29e469b95e=E2=80=99) (well, the latter example only = saves a couple of bytes, but larger ones of course save more)=E2=80=A6 = It is therefore important to define a unique transformation back into a = text string so encoders can check that there will be no change. Also, = software that processes the data on the CBOR side needs to be able to = handle Tag-21 encoded strings where text strings were expected. Matching strings against some pattern and encoding them in binary could = also be used for other data such as UUIDs (tag 37). Here again, for a = schema-less application, we lack instructions on how exactly to convert = tag 37 back into text strings (which is also needed by the JSON-to-CBOR = converter to check whether the conversion to binary is safe). This is a = bit more questionable, as it overloads the semantic tag 37 =E2=80=9Cthis = is a UUID=E2=80=9D by an alternate meaning =E2=80=9Cthis could be a UUID = syntactically=E2=80=9D. We also have been thinking about defining = additional such tags for common information in YANG-CBOR, such as IP = addresses, which would then also be available for JSON conversion. With schema information, all this can be done more cleanly (e.g., see = how SenML handles =E2=80=9Cdata values=E2=80=9D in CBOR vs. in XML and = JSON). In any case, all the above is illustration for why I don=E2=80=99t think = there is a single =E2=80=9Cright=E2=80=9D conversion from JSON to CBOR. = Still, to enable generic implementations of that conversion, it would be = good to provide some guidelines. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 28 04:24:03 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B1126CBF for ; Mon, 28 May 2018 04:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=d5SMmwUK; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LQH96E1x 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 2pnLTFMZuMJU for ; Mon, 28 May 2018 04:23:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC54126CC4 for ; Mon, 28 May 2018 04:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527506632; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jeZHw5wfXLdKX27C+qzntv5DjZvyfr2nqcd/lpI7Rso=; b=d5SMmwUKiuSNtzIZdazrvmrhYCqjrxcxgUnewVyvAJTBuziu4gQgVaNALFXsylc7 DCOJyaLd4RB3UgFpJcrwixAofQOa74XjPlBB6hxrvg0YjuTPsqYU5qwimOFL+llS JDkEi4nizQakbilqdShmFn9psYStnzU3dMXuaG0lFcY=; X-AuditID: c1b4fb30-e45ff70000004da5-2f-5b0be6c84c54 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.13.19877.8C6EB0B5; Mon, 28 May 2018 13:23:52 +0200 (CEST) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESSHC011.ericsson.se (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 28 May 2018 13:23:51 +0200 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 28 May 2018 13:23:51 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 28 May 2018 13:23:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jeZHw5wfXLdKX27C+qzntv5DjZvyfr2nqcd/lpI7Rso=; b=LQH96E1xjGkx8szBHEbEpitBejsXKTxes7QBMQE5WIL1TD/KD5ah+zb7ZHBUnlgrurFs+s+V+ShopAS+ff2B7WkhF7dJEPKO+N4Kx8mzmBbVcAp4X5orC8efB6QsdGTXAsELDyXdUzz0i6RCLQby/k7hknmReYTHUTF5KOggJYI= Received: from AMSPR07MB344.eurprd07.prod.outlook.com (10.242.20.149) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Mon, 28 May 2018 11:23:50 +0000 Received: from AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::bca1:3573:d81:2b1]) by AMSPR07MB344.eurprd07.prod.outlook.com ([fe80::bca1:3573:d81:2b1%5]) with mapi id 15.20.0797.011; Mon, 28 May 2018 11:23:50 +0000 From: Francesca Palombini To: Jim Schaad , 'Jeffrey Yasskin' , "draft-ietf-cbor-7049bis@ietf.org" CC: "cbor@ietf.org" , "cbor-chairs@ietf.org" Thread-Topic: [Cbor] Progressing work on draft-ietf-cbor-7049bis Thread-Index: AdPdaLX8Y4h/ih/5T5G03fZliVt7GwW7CMQAAAhoxoAAf0sDUA== Date: Mon, 28 May 2018 11:23:49 +0000 Message-ID: References: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> In-Reply-To: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [185.90.177.181] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 7:hiIdASD2VKjrRADgW8TEafzOhd0WRMv6HhrfmADwiYdiqhTH62o+SBSqXluKInUCcA7DyLJeJjkKiGGMwVVzNWGWPKmbZSwAJsBSFzyYR/FPkNlHp/RF/w7NE4aA9juy9XnsJtbCANtV4fx2t7+QdhaCKUt2dQVFgNWDpxkV854Icxe1yYpdrjW5IwTsgvky5iM98rViPt9KUToBTcMOg0qPfYEynMLw8FdLUp2ih2NibnfsxsXWAUQU1BNI44RN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AMSPR07MB456; x-ms-traffictypediagnostic: AMSPR07MB456: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(39380400002)(366004)(396003)(53754006)(199004)(54164003)(189003)(3280700002)(478600001)(229853002)(606006)(97736004)(316002)(33656002)(7736002)(14454004)(966005)(105586002)(106356001)(86362001)(6306002)(54896002)(5660300001)(9686003)(3660700001)(55016002)(6436002)(99286004)(236005)(2906002)(4326008)(790700001)(6116002)(53936002)(446003)(11346002)(486006)(476003)(102836004)(25786009)(26005)(6246003)(76176011)(6506007)(7696005)(3846002)(53546011)(44832011)(59450400001)(186003)(81166006)(2501003)(2900100001)(81156014)(8936002)(8676002)(19609705001)(54906003)(66066001)(5250100002)(74316002)(68736007)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB344.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: aUGtJd0pAl/h5shtVHOZtwuYWE+BzK8v7Haczvo+7+/uwMfrySz49vrbVtV+vh9rBz+vdnZ+q4DD51hLSTdLVFtFLmA5hgSpiJzOIjKkYvSMZdbaKR37GARZHwq8GxuEnc7XI86IIJrLwfFfgkfpE+hmz7abSkP1gEYbdL9SYnYWYJI/r4CxVr0xZRswz58V spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMSPR07MB34499BDBE31F81FBE2BC49B986E0AMSPR07MB344eurprd_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f9bd5324-f679-41ea-3e34-08d5c48d7c82 X-MS-Exchange-CrossTenant-Network-Message-Id: f9bd5324-f679-41ea-3e34-08d5c48d7c82 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2018 11:23:50.0042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGvTPTzrRYvVaQExQNNcYlKYIa0xAC6BMk7vpgIFEKjFItSzoI YkxEETFFKiL7JhJApMhalKBGbUyVFxRFiUDUWgJCYlgCYlnETqcmvH3n/Of8/703lyHlz0Ve jCY+idXFq7UKsZQqPvlkt/LtsFuE358FT1Xpogmpim8WUir70iNCZSycFasM1hpxiCi0paxQ HFqa1kOFVlfbiSNkuDQwhtVqklndzqBIaWxzxbFEQw26+KFZT6ehwUqkRxIG8B74+eOdmGc5 fo2gvihYj6QONiEw3W0lBeE3gnm7RBCqCSj8bKP5gsI5JHztLyIF5Q4BVZkjhFAMImhYMDqN xTgQ3lvHRbzgjssR2LqGncYkPgG5tUOOIYZZi4Nh7Ks/33bHIaBv/yIWeD8YX81QPFN4C+Qu VRL8uAyHQ0NGoJDVh6Cibtx5IYlj99qnIac9wt4wfdXoivKE/qF7hHBpDNXP3pECe8Co7a9I YAVM2WZpgb3hw70sxAcAbiPgV1W368WUMJGfTwpCOwJjQZPLdTtY0+tcydHQO2BwOWmgs2OO 4k8N+Dxkdm8Q2huhPttK5SD/kmXnEzgBzE2TNM8yvAa6ioeoEsc26Uho6twpjPhAXpaVFngb ZJSV08v7lYiuRx4cy0XFnd21y5fVaaI5LiHeN55NakWOT/XKNO/XgUZH9pkRZpBipWzY5hYh F6mTudQ4MwKGVLjLpEpphFwWo069xOoSTusuaFnOjNYzlMJTpjrUFi7HZ9VJ7HmWTWR1/1WC kXilodS+dfSF2fHNQVcO9G5Vhtk3jRsW0zvPnOE6Nz1ovLhbEnajfO+EtrbSkoIML8fMKZ4W e4boheXhufe33nRdlljyqiQS08fWbyuijx5uCng6611bqp+eWd1z/3t/49Sp7JYAEx1luq7J Oljw+OXt0rC5DI3v8ZxVtWMnIn18Biar8hQUF6v230HqOPU/cG3xzVADAAA= Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 11:24:01 -0000 --_000_AMSPR07MB34499BDBE31F81FBE2BC49B986E0AMSPR07MB344eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBoYXZlIGxlZnQgZW5vdWdoIHRpbWUgdG8gbGV0IHRoZXNlIFBSIGJlaW5n IGRpc2N1c3NlZC4gQWNjb3JkaW5nIHRvIHRoZSByZXNwb25zZSBvbiBnaXRodWIgYW5kIHRoZSB0 aHJlYWRzIGluIGhlcmUsIEkgdGhpbmsgaXQgaXMgdGltZSB0byBtZXJnZTogMTQsIDE1LCAxOSwg MjAuIEF1dGhvcnMsIGNvdWxkIHlvdSBnbyBvbiBhbmQgbWVyZ2UgdGhlc2U/DQoNCkppbSwgd291 bGQgeW91IGJlIGFibGUgdG8gb3BlbiBhbiBpc3N1ZSAob3IgYSBtYWlsIHRocmVhZCkvIHByb3Bv c2UgYSBjaGFuZ2UgdG8gZml4IHRoZSBwcm9ibGVtIHdpdGggdGhlIG9yaWdpbmFsIGxhbmd1YWdl IHlvdSBtZW50aW9uIGJlbG93Pw0KDQoxNyBhbmQgMTggYXJlIHN0aWxsIHVuZGVyIGRpc2N1c3Np b24uDQoNCk5vdGUgdGhhdCBzb21lIG5ldyBQUiBoYXZlIGJlZW4gb3BlbmVkICgyNCwgMjUpOiBk aXNjdXNzaW9uIGlzIGdvaW5nIG9uIChnaXRodWIgaXNzdWVzIGFuZCBtYWlsaW5nIGxpc3QpLCBz byBtYWtlIHN1cmUgdG8gdm9pY2UgeW91ciBvcGluaW9uIGlmIHlvdSBoYXZlIGFueS4NCg0KVGhh bmtzIHRvIGV2ZXJ5Ym9keSB3aG8gaXMgcGFydGljaXBhdGluZyENCkZyYW5jZXNjYQ0KDQpGcm9t OiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KU2VudDogZGVuIDI2IG1haiAy MDE4IDAwOjIwDQpUbzogJ0plZmZyZXkgWWFzc2tpbicgPGp5YXNza2luQGNocm9taXVtLm9yZz47 IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPg0K Q2M6IGNib3JAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzQGlldGYub3JnOyBjYm9y LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtDYm9yXSBQcm9ncmVzc2luZyB3b3JrIG9u IGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzDQoNCg0KDQpGcm9tOiBDQk9SIDxjYm9yLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmNib3ItYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBKZWZm cmV5IFlhc3NraW4NClNlbnQ6IEZyaWRheSwgTWF5IDI1LCAyMDE4IDExOjE5IEFNDQpUbzogRnJh bmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb208bWFpbHRv OmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPj4NCkNjOiBjYm9yQGlldGYub3JnPG1h aWx0bzpjYm9yQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXNAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzQGlldGYub3JnPjsgY2Jvci1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOmNib3ItY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDYm9yXSBQcm9n cmVzc2luZyB3b3JrIG9uIGRyYWZ0LWlldGYtY2Jvci03MDQ5YmlzDQoNCk15IGltcHJlc3Npb24g b2YgdGhlIHN0YXRlIG9mIHRoZXNlIFBScyBpczoNCg0KT24gVGh1LCBBcHIgMjYsIDIwMTggYXQg NzoxNCBBTSBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pQGVyaWNzc29u LmNvbTxtYWlsdG86ZnJhbmNlc2NhLi5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSBhbGwsDQoNCkluIG9yZGVyIHRvIHByb2dyZXNzIHRoZSBkcmFmdCwgSeKAmWQgbGlrZSB5b3Ug dG8gdGFrZSBhIGxvb2sgYXQgSmVmZnJleeKAmXMgcHJvcG9zYWxzIChxdW90ZWQgc2VsZWN0ZWQg dGV4dCBmcm9tIGhpcyBtYWlsIGJlbG93KS4NCg0KT25seSBQUjE3IGhhcyBnb3R0ZW4gb25lIGNv bW1lbnQgc28gZmFyIChsZXTigJlzIGRpc2N1c3MgaXQgZnVydGhlcikuIE5vdGUgdGhhdCB0aGUg UFIgd2VyZSBzdWJtaXR0ZWQgbW9yZSB0aGFuIGEgbW9udGggYWdvLCBpZiBJIGhlYXIgbm8gb2Jq ZWN0aW9ucyB0byB0aGVtIGJlZm9yZSB0aGUgMTF0aCBvZiBNYXksIHdl4oCZbGwgYXNrIHRoZSBl ZGl0b3JzIHRvIGdvIGFoZWFkIGFuZCBtZXJnZSB0aGVtLCBzbyBwbGVhc2UgdGFrZSBhIGxvb2sg YW5kIHNwZWFrIHVwLiBFdmVuIGEg4oCcKzHigJ0gaXMgdXNlZnVsLg0KDQpCaWcgUFI6DQpodHRw czovL2dpdGh1Yi5jb20vY2Jvci13Zy9DQk9SYmlzL3B1bGwvMTcgaGFzIGEgbG90IG9mIGNoYW5n ZXMgdG8gZGVmaW5lIHdoaWNoIGtpbmRzIG9mIENCT1IgcGFyc2VycyBuZWVkIHRvIGRldGVjdCB3 aGljaCBlcnJvcnMgaW4gdGhlIGVuY29kZWQgZGF0YSwgYW5kIHdoaWNoIGVycm9ycyBhcmUgcmVj b3ZlcmFibGUuDQoNClN0aWxsIHVuZGVyIGRpc2N1c3Npb24uDQoNCmh0dHBzOi8vZ2l0aHViLmNv bS9jYm9yLXdnL0NCT1JiaXMvcHVsbC8xOCBkZWZpbmVzIHdoZW4gdGhlIGtub3duIGtpbmRzIG9m IHRhZ2dlZCBpdGVtcyBhcmUgdmFsaWQuDQoNClRoZSBvbmx5IG9iamVjdGlvbiBtaXN1bmRlcnN0 b29kIHdoaWNoIHRleHQgSSByZW1vdmVkLCBzbyB0aGlzIGlzIHByb2JhYmx5IG9rIHRvIG1lcmdl LiBJdHMgZGVzY3JpcHRpb24gb2YgdGFnIDM1IGlzIHN0aWxsIHNvbWV3aGF0IGFtYmlndW91cyBi ZWNhdXNlIFBDUkUgYW5kIEVDTUFTY3JpcHQgaGF2ZSBkaWZmZXJlbnQgc2V0cyBvZiB2YWxpZCBy ZWd1bGFyIGV4cHJlc3Npb25zLCBidXQgSSB0aGluayBpdCdzIHN0aWxsIGFuIGltcHJvdmVtZW50 IG92ZXIgd2hhdCB3YXMgdGhlcmUgYmVmb3JlLg0KDQpbSkxTXSBJIGhhdmUgbm8gcmVhbCBvcGlu aW9uIG9uIHRoaXMgc2V0IG9mIGNoYW5nZXMNCg0KTWlub3IgUFI6DQpodHRwczovL2dpdGh1Yi5j b20vY2Jvci13Zy9DQk9SYmlzL3B1bGwvMTQgcmVtb3ZlcyB0aGUgZHVwbGljYXRlIERhdGEgTW9k ZWxzIHNlY3Rpb24uDQoNCk5vIGNvbW1lbnRzIGF0IGFsbCwgYW5kIHRoaXMgaXMgcHJvYmFibHkg dW5jb250cm92ZXJzaWFsLg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2Jvci13Zy9DQk9SYmlzL3B1 bGwvMTkgZml4ZXMgYW4gZXhhbXBsZSBvZiBKYXZhc2NyaXB0IGJlaW5nIHVuYWJsZSB0byBkaXN0 aW5ndWlzaCBzdHJpbmdzIGZyb20gbnVtYmVycyB3aGVuIHRoZXkncmUgdXNlZCBhcyBtYXAga2V5 cw0KDQpPbmUgY29tbWVudCBmcm9tIEppbSBsZWQgdG8gbWUgdXBkYXRpbmcgdGhlIEVDTUFTY3Jp cHQgcmVmZXJlbmNlLg0KDQpbSkxTXSBNeSBvbmx5IHByb2JsZW0gd2l0aCB0aGlzIGhhcyBtb3Jl IHRvIGRvIHdpdGggdGhlIG9yaWdpbmFsIGxhbmd1YWdlICB0aGFuIHdpdGggYW55IGNoYW5nZXMg KHRoZSBwcm9ibGVtIEkgaGF2ZSBpcyBzdGlsbCB0aGVyZSkuICBJIHdvdWxkIG5vdCBibG9jayBh bnl0aGluZyBvbiB0aGUgcHJvYmxlbSBJIGhhdmUgYXMgaXQgaXMgcHJvYmFibHkganVzdCBtZS4N Cg0KaHR0cHM6Ly9naXRodWIuY29tL2Nib3Itd2cvQ0JPUmJpcy9wdWxsLzIwL2ZpbGVzIGNoYW5n ZXMgYSBzdGF0ZW1lbnQgdGhhdCBkZXBlbmRpbmcgb24gbWFwIG9yZGVyICJ3b3VsZCBiZSB2ZXJ5 IGJhZCBwcmFjdGljZSIgaW4gcHJvdG9jb2xzIHVzaW5nIENCT1IgdG8gYSBzdGF0ZW1lbnQgdGhh dCB0aGVzZSBwcm90b2NvbHMgIk1VU1QgTk9UIiBkbyB0aGF0Lg0KDQpKaW0gd29uZGVyZWQgd2hl dGhlciBkZWNsYXJpbmcgYSBtYXAgb3JkZXJpbmcgdG8gYmUgYW4gZXJyb3IgY29uc3RpdHV0ZXMg YSBjaGFuZ2UgdG8gdGhlIHNlbWFudGljcyBiYXNlZCBvbiBvcmRlcmluZywgYW5kIEkndmUgY2hh bmdlZCB0aGUgdGV4dCB0byBiZSBjbGVhciB0aGF0IGl0J3MgYWxsb3dlZC4NCg0KW0pMU10gTm8g cHJvYmxlbXMgd2l0aCB0aGlzIHVwZGF0ZQ0KDQpUaGFua3MsDQpKZWZmcmV5DQo= --_000_AMSPR07MB34499BDBE31F81FBE2BC49B986E0AMSPR07MB344eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj5IaSBh bGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iU1YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIGhhdmUgbGVmdCBlbm91Z2ggdGltZSB0byBsZXQgdGhlc2UgUFIgYmVpbmcgZGlzY3Vzc2Vk LiBBY2NvcmRpbmcgdG8gdGhlIHJlc3BvbnNlIG9uIGdpdGh1YiBhbmQgdGhlIHRocmVhZHMgaW4g aGVyZSwgSSB0aGluayBpdCBpcyB0aW1lIHRvIG1lcmdlOiAxNCwgMTUsIDE5LCAyMC4gQXV0aG9y cywgY291bGQgeW91IGdvIG9uIGFuZCBtZXJnZSB0aGVzZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SmltLCB3b3VsZCB5b3UgYmUgYWJsZSB0byBvcGVuIGFuIGlzc3VlIChvciBhIG1haWwgdGhy ZWFkKS8gcHJvcG9zZSBhIGNoYW5nZSB0byBmaXggdGhlIHByb2JsZW0gd2l0aCB0aGUgb3JpZ2lu YWwgbGFuZ3VhZ2UgeW91IG1lbnRpb24gYmVsb3c/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjE3 IGFuZCAxOCBhcmUgc3RpbGwgdW5kZXIgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Tm90ZSB0aGF0IHNvbWUgbmV3IFBSIGhhdmUgYmVlbiBvcGVuZWQgKDI0LCAyNSk6IGRpc2N1 c3Npb24gaXMgZ29pbmcgb24gKGdpdGh1YiBpc3N1ZXMgYW5kIG1haWxpbmcgbGlzdCksIHNvIG1h a2Ugc3VyZSB0byB2b2ljZSB5b3VyIG9waW5pb24gaWYgeW91IGhhdmUgYW55LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MgdG8gZXZlcnlib2R5IHdobyBpcyBwYXJ0aWNpcGF0aW5nITxi cj4NCkZyYW5jZXNjYTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAyNiBtYWogMjAxOCAwMDoyMDxicj4NCjxiPlRv OjwvYj4gJ0plZmZyZXkgWWFzc2tpbicgJmx0O2p5YXNza2luQGNocm9taXVtLm9yZyZndDs7IEZy YW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gY2JvckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXNA aWV0Zi5vcmc7IGNib3ItY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb Q2Jvcl0gUHJvZ3Jlc3Npbmcgd29yayBvbiBkcmFmdC1pZXRmLWNib3ItNzA0OWJpczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IENCT1IgJmx0OzxhIGhyZWY9Im1haWx0bzpjYm9yLWJvdW5j ZXNAaWV0Zi5vcmciPmNib3ItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkplZmZyZXkgWWFzc2tpbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAyNSwg MjAxOCAxMToxOSBBTTxicj4NCjxiPlRvOjwvYj4gRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tIj5mcmFuY2VzY2Eu cGFsb21iaW5pQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86Y2JvckBpZXRmLm9yZyI+Y2JvckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWNib3ItNzA0OWJpc0BpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWNib3ItNzA0OWJp c0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjYm9yLWNoYWlyc0BpZXRmLm9yZyI+Y2Jv ci1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ2Jvcl0gUHJv Z3Jlc3Npbmcgd29yayBvbiBkcmFmdC1pZXRmLWNib3ItNzA0OWJpczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgaW1wcmVzc2lv biBvZiB0aGUgc3RhdGUgb2YgdGhlc2UgUFJzIGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciAyNiwgMjAxOCBhdCA3OjE0 IEFNIEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuY2VzY2EuLnBh bG9tYmluaUBlcmljc3Nvbi5jb20iPmZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5IaSBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBvcmRlciB0byBwcm9ncmVzcyB0 aGUgZHJhZnQsIEnigJlkIGxpa2UgeW91IHRvIHRha2UgYSBsb29rIGF0IEplZmZyZXnigJlzIHBy b3Bvc2FscyAocXVvdGVkIHNlbGVjdGVkIHRleHQgZnJvbSBoaXMgbWFpbCBiZWxvdykuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Pbmx5IFBSMTcgaGFzIGdvdHRlbiBvbmUgY29tbWVudCBz byBmYXIgKGxldOKAmXMgZGlzY3VzcyBpdCBmdXJ0aGVyKS4gTm90ZSB0aGF0IHRoZSBQUiB3ZXJl IHN1Ym1pdHRlZCBtb3JlIHRoYW4gYSBtb250aCBhZ28sIGlmIEkgaGVhciBubyBvYmplY3Rpb25z IHRvIHRoZW0gYmVmb3JlIHRoZSAxMTxzdXA+dGg8L3N1cD4NCiBvZiBNYXksIHdl4oCZbGwgYXNr IHRoZSBlZGl0b3JzIHRvIGdvIGFoZWFkIGFuZCBtZXJnZSB0aGVtLCBzbyBwbGVhc2UgdGFrZSBh IGxvb2sgYW5kIHNwZWFrIHVwLiBFdmVuIGEg4oCcJiM0Mzsx4oCdIGlzIHVzZWZ1bC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkJpZyBQUjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9j Ym9yLXdnL0NCT1JiaXMvcHVsbC8xNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5odHRwczovL2dpdGh1Yi5jb20vY2Jvci13Zy9DQk9SYmlzL3B1bGwvMTc8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJTViI+DQo8L3NwYW4+aGFzIGEgbG90IG9mIGNoYW5nZXMgdG8gZGVm aW5lIHdoaWNoIGtpbmRzIG9mIENCT1IgcGFyc2VycyBuZWVkIHRvIGRldGVjdCB3aGljaCBlcnJv cnMgaW4gdGhlIGVuY29kZWQgZGF0YSwgYW5kIHdoaWNoIGVycm9ycyBhcmUgcmVjb3ZlcmFibGUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RpbGwgdW5kZXIgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2Nib3Itd2cvQ0JPUmJpcy9wdWxsLzE4IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS9jYm9y LXdnL0NCT1JiaXMvcHVsbC8xODwvc3Bhbj48L2E+PC9zcGFuPiBkZWZpbmVzIHdoZW4NCiB0aGUg a25vd24ga2luZHMgb2YgdGFnZ2VkIGl0ZW1zIGFyZSB2YWxpZC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgb25seSBvYmplY3Rpb24gbWlzdW5kZXJzdG9vZCB3aGljaCB0ZXh0IEkgcmVt b3ZlZCwgc28gdGhpcyBpcyBwcm9iYWJseSBvayB0byBtZXJnZS4gSXRzIGRlc2NyaXB0aW9uIG9m IHRhZyAzNSBpcyBzdGlsbCBzb21ld2hhdCBhbWJpZ3VvdXMgYmVjYXVzZSBQQ1JFIGFuZCBFQ01B U2NyaXB0IGhhdmUgZGlmZmVyZW50IHNldHMgb2YgdmFsaWQgcmVndWxhciBleHByZXNzaW9ucywg YnV0IEkgdGhpbmsgaXQncw0KIHN0aWxsIGFuIGltcHJvdmVtZW50IG92ZXIgd2hhdCB3YXMgdGhl cmUgYmVmb3JlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bSkxTXSBJIGhhdmUgbm8gcmVhbCBv cGluaW9uIG9uIHRoaXMgc2V0IG9mIGNoYW5nZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaW5vciBQUjo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9jYm9yLXdnL0NCT1JiaXMvcHVsbC8xNCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20vY2Jvci13Zy9DQk9SYmlzL3B1bGwvMTQ8L3Nw YW4+PC9hPjwvc3Bhbj4gcmVtb3ZlcyB0aGUNCiBkdXBsaWNhdGUgRGF0YSBNb2RlbHMgc2VjdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBjb21tZW50cyBhdCBhbGwsIGFuZCB0aGlzIGlzIHBy b2JhYmx5IHVuY29udHJvdmVyc2lhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL2Nib3Itd2cvQ0JPUmJpcy9wdWxsLzE5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS9jYm9yLXdnL0NCT1JiaXMvcHVsbC8xOTwv c3Bhbj48L2E+PC9zcGFuPiBmaXhlcyBhbiBleGFtcGxlDQogb2YgSmF2YXNjcmlwdCBiZWluZyB1 bmFibGUgdG8gZGlzdGluZ3Vpc2ggc3RyaW5ncyBmcm9tIG51bWJlcnMgd2hlbiB0aGV5J3JlIHVz ZWQgYXMgbWFwIGtleXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgY29tbWVudCBmcm9tIEppbSBs ZWQgdG8gbWUgdXBkYXRpbmcgdGhlIEVDTUFTY3JpcHQgcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5bSkxTXSBNeSBvbmx5IHByb2JsZW0gd2l0aCB0aGlzIGhhcyBtb3JlIHRvIGRv IHdpdGggdGhlIG9yaWdpbmFsIGxhbmd1YWdlICZuYnNwO3RoYW4gd2l0aCBhbnkgY2hhbmdlcyAo dGhlIHByb2JsZW0gSSBoYXZlIGlzIHN0aWxsIHRoZXJlKS4mbmJzcDsgSSB3b3VsZCBub3QgYmxv Y2sgYW55dGhpbmcgb24gdGhlIHByb2JsZW0gSSBoYXZlIGFzIGl0IGlzIHByb2JhYmx5IGp1c3Qg bWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jYm9yLXdnL0NC T1JiaXMvcHVsbC8yMC9maWxlcyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5o dHRwczovL2dpdGh1Yi5jb20vY2Jvci13Zy9DQk9SYmlzL3B1bGwvMjAvZmlsZXM8L3NwYW4+PC9h Pjwvc3Bhbj4NCiBjaGFuZ2VzIGEgc3RhdGVtZW50IHRoYXQgZGVwZW5kaW5nIG9uIG1hcCBvcmRl ciAmcXVvdDt3b3VsZCBiZSB2ZXJ5IGJhZCBwcmFjdGljZSZxdW90OyBpbiBwcm90b2NvbHMgdXNp bmcgQ0JPUiB0byBhIHN0YXRlbWVudCB0aGF0IHRoZXNlIHByb3RvY29scyAmcXVvdDtNVVNUIE5P VCZxdW90OyBkbyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkppbSB3b25kZXJlZCB3aGV0aGVy IGRlY2xhcmluZyBhIG1hcCBvcmRlcmluZyB0byBiZSBhbiBlcnJvciBjb25zdGl0dXRlcyBhIGNo YW5nZSB0byB0aGUgc2VtYW50aWNzIGJhc2VkIG9uIG9yZGVyaW5nLCBhbmQgSSd2ZSBjaGFuZ2Vk IHRoZSB0ZXh0IHRvIGJlIGNsZWFyIHRoYXQgaXQncyBhbGxvd2VkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bSkxTXSBObyBwcm9ibGVtcyB3aXRoIHRoaXMgdXBkYXRlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkplZmZyZXkmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AMSPR07MB34499BDBE31F81FBE2BC49B986E0AMSPR07MB344eurprd_-- From nobody Mon May 28 05:49:41 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862601289B0; Mon, 28 May 2018 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOQ13jVvkymT; Mon, 28 May 2018 05:49:37 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B11128896; Mon, 28 May 2018 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4SCnN3o017910; Mon, 28 May 2018 14:49:23 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40vcBB5Q2xzDX2F; Mon, 28 May 2018 14:49:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Mon, 28 May 2018 14:49:21 +0200 Cc: Jim Schaad , Jeffrey Yasskin , "draft-ietf-cbor-7049bis@ietf.org" , "cbor@ietf.org" , "cbor-chairs@ietf.org" X-Mao-Original-Outgoing-Id: 549204560.332117-1bc6d1c2f5ee83406a6059160670ec9a Content-Transfer-Encoding: quoted-printable Message-Id: References: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 12:49:40 -0000 On May 28, 2018, at 13:23, Francesca Palombini = wrote: >=20 > I think it is time to merge: 14, 15, 19, 20. Authors, could you go on = and merge these? This week is a good week for getting merges done. Contributors: Please do not make formatting changes that are unrelated = to the part that you are proposing to change. This creates merge = conflicts and obscures the changes that actually are being made. (Yes, = the source is somewhat inconsistently formatted in some places =E2=80=94 = the damage to version control from fixing this is much larger than the = slight discomfort we experience when we are editing it.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 28 06:07:41 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C9126C26 for ; Mon, 28 May 2018 06:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvUFe4Y3Ik4e for ; Mon, 28 May 2018 06:07:39 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4471200C1 for ; Mon, 28 May 2018 06:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4SD7ZYR002674 for ; Mon, 28 May 2018 15:07:35 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40vcbC2cHszDX2S; Mon, 28 May 2018 15:07:35 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 549205652.971487-96095421773ebd23a19c0b0132d73363 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 28 May 2018 15:07:34 +0200 Message-Id: <8B6ACE89-6939-46B5-8BF9-CC9C9A0EE76E@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] Background Information (PR #26) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 13:07:41 -0000 Burt has started collecting some information about the backdrop in front = of which CBOR was created in PR #26. I think this is interesting = material, but like most =E2=80=9Chistory of computing=E2=80=9D style = collection, it will take some effort to get it right and reasonably = complete. E.g., I=E2=80=99d sure like to talk to the people who where = there when RFC 713 was created and get a more complete picture of their = thinking. All in all, this makes a nice project for a couple of years = of on-and-off work, but doesn=E2=80=99t quite fit into the schedule we = have set ourselves for the CBORbis work. Should we maybe start a separate document for background information = like this? Maybe we can add some background information on = canonicalization=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 28 10:31:20 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2E12D953 for ; Mon, 28 May 2018 10:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WomhGKqxW_I1 for ; Mon, 28 May 2018 10:31:16 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BA512D948 for ; Mon, 28 May 2018 10:31:16 -0700 (PDT) Received: from Jude (192.168.1.166) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 28 May 2018 10:28:25 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <8B6ACE89-6939-46B5-8BF9-CC9C9A0EE76E@tzi.org> In-Reply-To: <8B6ACE89-6939-46B5-8BF9-CC9C9A0EE76E@tzi.org> Date: Mon, 28 May 2018 10:31:07 -0700 Message-ID: <015601d3f6a9$ab3c2d70$01b48850$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDQ5xioKVBbT5wvJT+klNwohox6WaZLgWWQ Content-Language: en-us X-Originating-IP: [192.168.1.166] Archived-At: Subject: Re: [Cbor] Background Information (PR #26) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 17:31:19 -0000 I am not sure that I find the history lesson to be especially useful for = this document. Much of the information presented seems to be completely = unrelated to anything (why have section on ASCII?), some of it may cause = people to become more defensive about things (one throw away line on = ASN.1 is not going to get me mad, but a large dis of it is going to = cause me to make lots of arguments) and none if it seems to be helpful = to the goal of the document which is to describe what CBOR is and how to = use it. I agree with Carsten that getting this right is going to take = far longer than we can currently afford. Jim > -----Original Message----- > From: CBOR On Behalf Of Carsten Bormann > Sent: Monday, May 28, 2018 6:08 AM > To: cbor@ietf.org > Subject: [Cbor] Background Information (PR #26) >=20 > Burt has started collecting some information about the backdrop in = front of > which CBOR was created in PR #26. I think this is interesting = material, but like > most =E2=80=9Chistory of computing=E2=80=9D style collection, it will = take some effort to get it > right and reasonably complete. E.g., I=E2=80=99d sure like to talk to = the people who > where there when RFC 713 was created and get a more complete picture = of > their thinking. All in all, this makes a nice project for a couple of = years of on- > and-off work, but doesn=E2=80=99t quite fit into the schedule we have = set ourselves > for the CBORbis work. >=20 > Should we maybe start a separate document for background information = like > this? Maybe we can add some background information on = canonicalization=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > CBOR mailing list > CBOR@ietf.org > https://www.ietf.org/mailman/listinfo/cbor From nobody Mon May 28 16:01:54 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFFE12E878 for ; Mon, 28 May 2018 16:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmGE2bm_E83X for ; Mon, 28 May 2018 16:01:51 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-oln040092011025.outbound.protection.outlook.com [40.92.11.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E021512E870 for ; Mon, 28 May 2018 16:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hCqwNoK882Km5qxmLumSDJDS8swKsSv+8bnC+7jOtmM=; b=M5R0BIxuogRjxxuwtTjC8qMJHxdrX5BSkYsRXDt5vQPLRB2sK0x51XlYGKqMYnStR67qAez8P+0IsUxAFHeXyYx/5KATm2foXRisC7J9ed5argo2O1ZUn8YB7LqpB25T/ZRCY+d3afEEEBknWyg/NM3f1GXsumVe476Ntw7X+3Gjt8pteopKOOg/hqUfFWf1fu2UNmIEivHxUlWIMClCCsn7XiFq+vPTkYcWCaN+dr19+80/q4tbwuIedCZL4EzycKkboJUhYuXY9vy4bc6sG2nKePzZqV9OO0H+Ar1GZOl3qgAsM43T6QtTwZ2eFSg+tyjCF3CJDzDB6cCnNw504g== Received: from CO1NAM04FT036.eop-NAM04.prod.protection.outlook.com (10.152.90.54) by CO1NAM04HT230.eop-NAM04.prod.protection.outlook.com (10.152.91.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.820.8; Mon, 28 May 2018 23:01:49 +0000 Received: from DM5PR22MB0924.namprd22.prod.outlook.com (10.152.90.52) by CO1NAM04FT036.mail.protection.outlook.com (10.152.91.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.820.8 via Frontend Transport; Mon, 28 May 2018 23:01:49 +0000 Received: from DM5PR22MB0924.namprd22.prod.outlook.com ([fe80::e1aa:d926:c261:9c8a]) by DM5PR22MB0924.namprd22.prod.outlook.com ([fe80::e1aa:d926:c261:9c8a%17]) with mapi id 15.20.0797.017; Mon, 28 May 2018 23:01:49 +0000 From: Burt Harris To: Carsten Bormann CC: Jim Schaad , "cbor@ietf.org" Thread-Topic: [Cbor] Consistent translations between JSON and CBOR Thread-Index: AdP0gF5N5vVwj5IZRmKPMZ109U5YegALd9cAAAGs8WAADHohAABweb1A Date: Mon, 28 May 2018 23:01:49 +0000 Message-ID: References: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:FFAC43962B9360D6B92CCD854C60DC4B970BA3323DB4D2006DD099125A05BAF6; UpperCasedChecksum:980717ED05B888AB6741D1F01D87FEAEC5B283DF682C968286AAA9948F9418B1; SizeAsReceived:7274; Count:46 x-tmn: [UQdsSSzh4zRRkgo+oaMAmtj/NgWvnoiC] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT230; 7:2RT8dKM76d5p0f53aWK3663XweVkjJKUAp9Hkf8gR+OGyiZwCHZNCSJ7CzF5MGxiBoP3FfeYC6VuckokCS5L2vJuvLNoFgvc/OW+bmWX2HX7jVCf5BWH+eB2sAK3TAnVKBQsFXrC16Ndp6j9gADw3LPpqvu9UJOKZbCbNJp27K/3wqoc/Lk1QFg0UdBB7o4DqUrnjoXlGpY0wAOvHQBJPWyXdMB4lo+b+q5lIUU+wU8C4dA5y8k/DxrjoqAKPG24 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125466)(1603101448)(1701031045); SRVR:CO1NAM04HT230; x-ms-traffictypediagnostic: CO1NAM04HT230: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM04HT230; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT230; x-forefront-prvs: 06860EDC7B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(81156014)(7696005)(8936002)(6346003)(2900100001)(3280700002)(73972006)(229853002)(9686003)(55016002)(83332001)(6246003)(5660300001)(76176011)(3660700001)(102836004)(86362001)(45080400002)(68736007)(26005)(14454004)(6506007)(8676002)(104016004)(33656002)(54906003)(5250100002)(6436002)(4326008)(99286004)(25786009)(20460500001)(105586002)(106356001)(74316002)(446003)(476003)(11346002)(97736004)(486006)(6916009)(305945005)(87572001)(93886005)(82202002)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT230; H:DM5PR22MB0924.namprd22.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=burt_harris@hotmail.com; x-microsoft-antispam-message-info: j/S26KmedxPp4jm/yHB1dmBTliLEbA0mK2pV1eAqaEgtshmSdaWGgU7eu6E2xTlKvEmSLRWWvAsfvzxAGSh3BXDVR1YcMS2mQaRHHdEBKCaJu9QHKCS8pqrUqaQvPzmDfJBftAaibLMpkgNBtWIi8yc61TPuzs/8svaoPqYNLACxTGE5IugsrxBKH2lK2ssc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a0d458f1-ad1d-4d33-3bd7-08d5c4eefe7d X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: a0d458f1-ad1d-4d33-3bd7-08d5c4eefe7d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2018 23:01:49.2892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT230 Archived-At: Subject: Re: [Cbor] Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 23:01:53 -0000 QXMgSSB1bmRlcnN0YW5kIGl0LCBDYXJzdGVuIGlzIHNheWluZyB0aGF0IENCT1IgdG9kYXkgcmVz ZXJ2ZXMgdGFnIDIxLTIzIGZvciBDQk9SIC0+IEpTT04gdHJhbnNsYXRvcnMuICAgVGhhdCBtaWdo dCBiZSBnb29kIGZvciBkZWJ1Z2dpbmcsIGJ1dCB0aGVyZSBpcyBubyBzYWZlIGFuZCBzdGFuZGFy ZCBhcHByb2FjaCB0byBnbyBmcm9tIEpTT04gLT4gQ0JPUiBvbiB0aGUgcm91bmQgdHJpcCBpZiB0 aGUgb3JpZ2luYWwgQ0JPUiBjb250YWluZWQgYmluYXJ5IGJlY2F1c2UgSlNPTiBkb2Vzbid0IGhh dmUgc3ludGF4IG9yIGJpbmFyeSBvciBzY2hlbWEuICAgSlNPTiBzdHJpbmcgSGV1cmlzdGljcyBs aWtlIG1hdGNoaW5nIHJlZ3VsYXIgZXhwcmVzc2lvbnMgZm9yIGJhc2UxNiwgYmFzZTMyLCBvciBi YXNlNjQgY291bGQgbWFrZSBzaW1wbGUgZXhhbXBsZXMgbGlrZSBgImJlZWYiYCBhbWJpZ3VvdXMg YXMgdG8gaWYgdGhleSBhcmUgYmluYXJ5IG9yIHRleHQsIGFuZCBpZiBiaW5hcnksIHdoaWNoIGZv cm1hdCEgICBUaGUgdGFncyBjYW4ndCBoZWxwIHRoYXQsIHJpZ2h0IENhcnN0ZW4/DQoNClRoYXQg bWFrZSBzZW5zZSB0byBtZS4gICBJIGtub3csIFlBTUwgYWxsb3dzIChidXQgZG9lcyBub3QgcmVx dWlyZSkgc2ltaWxhciBwYXR0ZXJuIG1hdGNoaW5nLCBidXQgaXQgb25seSBhcHBsaWVzIHRvIHVu cXVvdGVkIHN0cmluZ3MsIGFuZCBKU09OIGRvZXNuJ3QgaGF2ZSB1bnF1b3RlZCBzdHJpbmdzLiAg IFlBTUxzIHBhdHRlcm4gbWF0Y2hpbmcgc29sdXRpb24gbWF5IG5vdCBiZSBwZXJmZWN0LCBidXQg dGhlcmUgaXMgYW4gYWx0ZXJuYXRpdmUsIGAhIWJpbmFyeWAgbWVhbnMgYmFzZTY0LiAgIERpZCB5 b3UgY29uc2lkZXIgdXNpbmcgYSBZQU1MIHNlcmlhbGl6ZXIgaW5zdGVhZCBvZiBtYWtpbmcgdXAg Q0JPUiBkaWFnbm9zdGljIGxhbmd1YWdlPw0KDQpNaWNyb3NvZnQgSW50ZXJ2aWV3IFRhY3RpY3Mu Li4NCg0KQmVsb3cgaXMgdGhlIHNvcnQgb2YgdGhpbmcgd2UgdXNlZCB0byBkcmVhbSB1cCBmb3Ig aW50ZXJ2aWV3cyBhdCBNaWNyb3NvZnQgd2hlbiBJIHdvcmtlZCB0aGVyZS4gIFlvdSBtaWdodCBm aW5kIGl0IGZ1bi4gICBBIHRydWUgY29uc3VsdGFudCdzIGFuc3dlciBtaWdodCBiZSAiaXQgZGVw ZW5kcyIsIHdoaWNoIGlzIGNvcnJlY3QsIGJ1dCBub3QgYXMgbXVjaCBhcyBzb21lb25lIG1pZ2h0 IGltYWdpbmUuICAgQ2FuIGFueW9uZSBvdXQgdGhlcmUgbWFrZSBub3RlIG9mIHN1cnByaXNpbmcg YW5zd2VycyBmcm9tIHJ1bm5pbmcgaXQgaW4gYSBwYXJ0aWN1bGFyIGVudmlyb25tZW50PyBJIHdv dWxkIGJlIHF1aXRlIGludGVyZXN0aW5nIHRvIGhlYXIgYWJvdXQsIGFuZCBJIHRoaW5rIGl0IG1h eSBiZSByZWxldmFudCB0byB0aGlzIGRpc2N1c3Npb246DQoNCkkgd2FzIG1vc3Qgc3VycHJpc2Vk IG9uIFdpbmRvd3MgMTAgTm9kZS5qcyAoYW55IHZlcnNpb24pIGF0IHRoZSBvdXRwdXQgcmVuZGVy aW5nIG9mIHRoZSBjb2xvbiBjaGFyYWN0ZXIgaW4gdGhlIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCBr ZXkgMy4gICBEb2VzIGFueW9uZSBlbHNlIHNlZSBzb21ldGhpbmcgZnVubnk/ICBDYXJlIHRvIGV4 cGxhaW4/DQoNCkJ1dCByZS4gQ0JPUjogIHNob3VsZCBzZW5kaW5nIHRoaXMgc2FtZSBkYXRhIHN0 cnVjdHVyZSB0aHJvdWdoIENCT1Igc2VyaWFsaXphdGlvbiAmIGRlc2VyaWFsaXphdGlvbiB3b3Jr PyAgV2l0aG91dCBjaGFuZ2luZyB0aGUgb3V0cHV0Pw0KDQpgYGANCi8vIEphdmFTY3JpcHQvSlNP TiBjb25zdWx0YW50J3MgdGVzdDogV2hhdCdzIHRoZSBvdXRwdXQ/ICBFeHRyYSBwb2ludHM6IHRy eSB3aXRob3V0IHJ1bm5pbmcgaXQuDQoNCnZhciBpc1RoaXNWYWxpZCA9IHsNCiAgIlEiOiAiSXMg dGhpcyB2YWxpZCBKYXZhU2NyaXB0PyIsDQogIDE6ICJkZWFkIGJlZWYiLA0KICAyOiAiXHVkZWFk IFx1YmVlZiIsDQogIDM6ICJcdURCMTY6IGRlYWQgYmVlZiIsDQogIDA6ICJObyBvZmZlbnNlIGlu dGVuZGVkLiIsDQogIC8vICJDQk9SIGRpYWdub3N0aWMgbm90YXRpb24gd29uJ3Qgd29yayI6IGgn ZGVhZCBiZWVmJywgDQogICJBIjogIlllcywgYnV0IHdoYXQgZG9lcyBpdCBhbGwgbWVhbj8iDQp9 Ow0KDQpmdW5jdGlvbiBsb2coeCkgeyBjb25zb2xlLmxvZyh4fHwiIik7IH0NCg0KbG9nKCk7DQps b2coIEpTT04uc3RyaW5naWZ5KGlzVGhpc1ZhbGlkKSApOw0KbG9nKCk7DQpsb2coIGlzVGhpc1Zh bGlkICk7DQpsb2coKTsNCmxvZyggaXNUaGlzVmFsaWRbM10uY2hhckNvZGVBdCgwKS50b1N0cmlu ZygxNikgICkNCmxvZyggaXNUaGlzVmFsaWRbM10uY29kZVBvaW50QXQoMCkudG9TdHJpbmcoMTYp ICApDQpsb2coKTsNCmBgYA0KDQo= From nobody Mon May 28 23:06:50 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871A412EA64 for ; Mon, 28 May 2018 23:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzrx8EH2omlO for ; Mon, 28 May 2018 23:06:46 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7EA12EA55 for ; Mon, 28 May 2018 23:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4T66fkA002760; Tue, 29 May 2018 08:06:41 +0200 (CEST) Received: from [192.168.217.102] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40w3C50NRrzDX97; Tue, 29 May 2018 08:06:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 29 May 2018 08:06:39 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 549266797.7196651-dc57d623c0ca5d6c4175fcc36dc8fcb1 Content-Transfer-Encoding: quoted-printable Message-Id: <4899A15C-4B85-4E7F-9D3E-6AB1C8015C0A@tzi.org> References: <000201d3f4ae$40684b20$c138e160$@augustcellars.com> To: Burt Harris X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] The role of YAML -- Re: Consistent translations between JSON and CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 06:06:48 -0000 Hi Burt, lots of interesting questions. Let me try addressing them in pieces. On May 29, 2018, at 01:01, Burt Harris wrote: >=20 > Did you consider using a YAML serializer instead of making up CBOR = diagnostic language? Absolutely. I personally use YAML as the diagnostic notation for my = CBOR-based work(*): e.g., when I open a binary CBOR file in Emacs, it is = automatically converted to YAML (and back when writing out). Section 6 = of RFC 7049 even recommends looking at YAML. However, YAML would have = been one more thing to learn for people who want to move on from JSON to = CBOR, so we thought relying on it too much would create more of a = threshold than we liked. (YAML also is not a formal standard that has = ongoing maintenance and a formal reference that would be immediately = acceptable as a normative reference in an RFC.) So the official = diagnostic notation of CBOR, as defined in Section 6 of RFC 7049, is = based on JSON and extends that, e.g., with binary data and tags. Gr=C3=BC=C3=9Fe, Carsten (*) Actually, I usually also look at JSON files after converting them to = the more readable YAML first :-) From nobody Tue May 29 05:07:13 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98C71275AB for ; Tue, 29 May 2018 05:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 3AlPN1hwyOU0 for ; Tue, 29 May 2018 05:07:10 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 A1FC312E03C for ; Tue, 29 May 2018 05:07:09 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 05:07:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,456,1520924400"; d="scan'208";a="59445157" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 29 May 2018 05:07:08 -0700 Received: from tjmaciei-mobl1.localnet (10.254.10.254) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 May 2018 05:07:08 -0700 From: Thiago Macieira To: Date: Tue, 29 May 2018 07:07:06 -0500 Message-ID: <9611299.FraEHbU4J7@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.254.10.254] Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgZXRj4oCm?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 12:07:12 -0000 On Friday, 25 May 2018 12:55:15 CDT Jeffrey Yasskin wrote: > FWIW, I don't think the names of the major types are a significant problem > in newcomers (which I was a year ago) understanding their meanings. > > While "string" would be ambiguous, "byte string" and "text string" are > pretty clear about their meanings. The remaining ambiguity is about the > encoding of a "text string", for which "utf-8 string" would be more > precise, but I don't think this is a big problem. Programmers are used to > having to look up which encoding(s) strings have in any particular > language. I tend to agree here. One of the reasons to use "string" in "byte string" is that low-level programmers (C and C++) are used of thinking of strings as an arbitrary sequence of bytes. Even the C++ type std::string is used like that, despite having some text-like functions. On the other hand, whenever we see "text", we think of human text, not arbitrary bytes. And more often than not, there's an association with Unicode. It's just a question of which of the UTFs is the one in use. So by contrasting to "text string", it's clear what "byte string" means. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Tue May 29 05:18:40 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D412DA70 for ; Tue, 29 May 2018 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ck9-0Ga43afg for ; Tue, 29 May 2018 05:18:37 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 8B5F712783A for ; Tue, 29 May 2018 05:18:37 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 05:18:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,456,1520924400"; d="scan'208";a="62567787" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga002.jf.intel.com with ESMTP; 29 May 2018 05:18:37 -0700 Received: from tjmaciei-mobl1.localnet (10.254.10.254) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 May 2018 05:18:36 -0700 From: Thiago Macieira To: Date: Tue, 29 May 2018 07:18:34 -0500 Message-ID: <5129942.60MZcr1EXU@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.254.10.254] Archived-At: Subject: Re: [Cbor] =?utf-8?q?CBOR-BIS_Terminology_Refinement_=3A_Maps_vs_Obj?= =?utf-8?b?ZWN0cywgZXRj4oCm?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 12:18:39 -0000 On Friday, 25 May 2018 21:08:51 CDT Burt Harris wrote: > Without naming him, I respect the author=E2=80=99s intent in saying it, b= ut I can=E2=80=99t > agree in detail. Here=E2=80=99s my logic for wanting CBOR-BIS to unamb= iguously > make his statement false: >=20 > 1) JSON text is encoded as UTF-8 (default), UTF-16 or UTF-32. (RFC 7159, > section 8.1, clarified in RFC 8259 section 8.1) Note that it's not just JSON strings you're talking about here. It's the=20 entire JSON document. In other words, the encoding for "true" is=20 U+0074 U+0072 U+0075 U+0065 And that gets transformed into either 4 bytes in UTF-8, 8 bytes in UTF-16 o= r=20 16 bytes with UTF-32. This wasn't a string. > 2) JSON strings are composed entirely of Unicode characters (RFC 8259 > section 8.2)=20 > 3) CBOR major type 2 is for bytes, without any implied encoding. (RFC 704= 9, > section 2.1. > 4) CBOR major type 3 is for UNICODE text encoded as UTF-8. (RFC 7049, > section 2.1.) > 5) CBOR treats JSON text is a sequence of characters, not encoded bytes (= RFC > 7049, section 4, confirming #2 above.) If you put a JSON document inside a CBOR Text String, which requires UTF-8,= =20 you're expected to encode it in UTF-8, even if the source was UTF-16 or=20 UTF-32. This transformation is lossless. If you need to guarantee byte-level fidelity of your payload so, for exampl= e,=20 you can validate a checksum or signature, you really want a CBOR Byte Strin= g,=20 not a Text one. By placing your JSON document -- even if the original was=20 UTF-8 encoded -- in a CBOR Text String and tagging it with one of the JSON= =20 descriptors, an intermediary could reprocess it and transform somehow, like= =20 sorting the keys in all JSON objects. This would destroy your ability to=20 perform the signature checking, even if the semantics of the data were=20 actually preserved. > IETF standards are generally very specific about things like character > encodings. Yet an experienced CBOR developer is telling me it=E2=80=99s = perfectly > OK to lose the character encoding information by converting JSON strings = as > CBOR binary strings. (Now if the CBOR binary string were preceded by a > tag (major type 6) indicating a specific character encoding, such as > ISO/IEC 8859-1:1998, I could accept the argument, but we don=E2=80=99t ha= ve such > string encoding tags specified yet.) It may seem a small point to a > person working in some specific programming language, but when > international and polyglot concerns are taken into effect, loosing > character encoding information is a very bad thing, but I think he > overgeneralized because of his language background I think this is a matter for a higher-level decision. If your protocol need= s=20 to transport extra metadata such as the encoding associated with your bag o= f=20 bytes, you should provide it in a field. It is probably a good idea to have= a=20 few tags for some common encodings, but your protocol should be designed to= =20 carry that in a text field of its own, as the encoding could be one for whi= ch=20 there's no corresponding tag. =2D-=20 Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nobody Tue May 29 11:29:21 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7112D93F for ; Tue, 29 May 2018 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnM_JhIQsWyD for ; Tue, 29 May 2018 11:29:03 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 DE6FA12EB59 for ; Tue, 29 May 2018 11:29:02 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id d10-v6so19663508itj.1 for ; Tue, 29 May 2018 11:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvUMTlSTNNuUz8l5X+VaV4E/YPNmeL55C8mhqn8AZ0o=; b=Rvpnn0F3vwCQnDYCElw4ekk6Pw6F8X74UDbNI9AwZbEG7JTQxh+dEvPi0VWA0f84qq GIMtxVE7QbwVSebAo0O4u5Vz1oSkVhfmB5CFG78cB28vuvE/5x+PPcj+xD2JE4AjJGD6 NL0u6wB5BjL8POQx7QsDPFGjYolrAbZi4x+oA= 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=dvUMTlSTNNuUz8l5X+VaV4E/YPNmeL55C8mhqn8AZ0o=; b=Z8blwLme9c8BwKjFijKQFlzdpI2ZvZrhJeb7b5YVYkWR40uG1HW7zdBuylHHFvGrBD KZfGxB2szNqqwDOK3h2tGvlb9wPKZNxzKEwCLnNSp7F8n80JxY6ofyJN7woGrBplDEkZ +QlaWG6lxXI/H2N8lh18Og3DzW8OsbCow1QAOJhGuz9fZRWt9sHgaJzhNeyQadl3aM1A 65V5PNLv/+tq7MLx8pfYdleWeKF9sk7p1LsGu9qWOvkPgrAXksr4cI/h4WK13sj8vjrq eszk0HwnC0uxv3fyrKxQaDcO0xoKDDhTh58p0SHqrCbohK1zlouXy0qyYuLVgJekAXfe getw== X-Gm-Message-State: APt69E0ZmYJMkRg3yM8vxgexs+vU4Ir6U2UlQB8Sk709qn8hepD9eXgS pOt7l8rsvhgkHX4pkEAb8LMXzoKXC4hUbVO/ObMogg== X-Google-Smtp-Source: ADUXVKLDGHdAkLUSNfqCT6R9LuHHRH443hAdz2m4B/1Cr2IetLKIIjfTO5jC3CooT4MIfBDFND6yf1pXHJ/kLP3i0Tc= X-Received: by 2002:a24:4455:: with SMTP id o82-v6mr31155ita.4.1527618541752; Tue, 29 May 2018 11:29:01 -0700 (PDT) MIME-Version: 1.0 References: <001101d3f476$7ed9fd50$7c8df7f0$@augustcellars.com> In-Reply-To: From: Jeffrey Yasskin Date: Tue, 29 May 2018 11:28:50 -0700 Message-ID: To: Francesca Palombini Cc: ietf@augustcellars.com, Jeffrey Yasskin , draft-ietf-cbor-7049bis@ietf.org, cbor@ietf.org, cbor-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000892fe0056d5c68ed" Archived-At: Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:29:19 -0000 --000000000000892fe0056d5c68ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 28, 2018 at 4:23 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi all, > > > > We have left enough time to let these PR being discussed. According to th= e > response on github and the threads in here, I think it is time to merge: > 14, 15, 19, 20. Authors, could you go on and merge these? > Thanks! I assume you mean that the editors should merge these, since I don't have write access. Jeffrey > > > Jim, would you be able to open an issue (or a mail thread)/ propose a > change to fix the problem with the original language you mention below? > > > > 17 and 18 are still under discussion. > > > > Note that some new PR have been opened (24, 25): discussion is going on > (github issues and mailing list), so make sure to voice your opinion if y= ou > have any. > > > > Thanks to everybody who is participating! > Francesca > > *From:* Jim Schaad > *Sent:* den 26 maj 2018 00:20 > *To:* 'Jeffrey Yasskin' ; Francesca Palombini < > francesca.palombini@ericsson.com> > *Cc:* cbor@ietf.org; draft-ietf-cbor-7049bis@ietf.org; > cbor-chairs@ietf.org > *Subject:* RE: [Cbor] Progressing work on draft-ietf-cbor-7049bis > > > > > > > > *From:* CBOR *On Behalf Of *Jeffrey Yasskin > *Sent:* Friday, May 25, 2018 11:19 AM > *To:* Francesca Palombini > *Cc:* cbor@ietf.org; draft-ietf-cbor-7049bis@ietf.org; > cbor-chairs@ietf.org > *Subject:* Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis > > > > My impression of the state of these PRs is: > > > > On Thu, Apr 26, 2018 at 7:14 AM Francesca Palombini < > francesca.palombini@ericsson.com > > wrote: > > Hi all, > > > > In order to progress the draft, I=E2=80=99d like you to take a look at Je= ffrey=E2=80=99s > proposals (quoted selected text from his mail below). > > > > Only PR17 has gotten one comment so far (let=E2=80=99s discuss it further= ). Note > that the PR were submitted more than a month ago, if I hear no objections > to them before the 11th of May, we=E2=80=99ll ask the editors to go ahead= and > merge them, so please take a look and speak up. Even a =E2=80=9C+1=E2=80= =9D is useful. > > > > Big PR: > > https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define > which kinds of CBOR parsers need to detect which errors in the encoded > data, and which errors are recoverable. > > > > Still under discussion. > > > > https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds > of tagged items are valid. > > > > The only objection misunderstood which text I removed, so this is probabl= y > ok to merge. Its description of tag 35 is still somewhat ambiguous becaus= e > PCRE and ECMAScript have different sets of valid regular expressions, but= I > think it's still an improvement over what was there before. > > > > [JLS] I have no real opinion on this set of changes > > > > Minor PR: > > https://github.com/cbor-wg/CBORbis/pull/14 removes the duplicate Data > Models section. > > > > No comments at all, and this is probably uncontroversial. > > > > https://github.com/cbor-wg/CBORbis/pull/19 fixes an example of Javascript > being unable to distinguish strings from numbers when they're used as map > keys > > > > One comment from Jim led to me updating the ECMAScript reference. > > > > [JLS] My only problem with this has more to do with the original language > than with any changes (the problem I have is still there). I would not > block anything on the problem I have as it is probably just me. > > > > https://github.com/cbor-wg/CBORbis/pull/20/files changes a statement that > depending on map order "would be very bad practice" in protocols using CB= OR > to a statement that these protocols "MUST NOT" do that. > > > > Jim wondered whether declaring a map ordering to be an error constitutes = a > change to the semantics based on ordering, and I've changed the text to b= e > clear that it's allowed. > > > > [JLS] No problems with this update > > > > Thanks, > > Jeffrey > --000000000000892fe0056d5c68ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 28= , 2018 at 4:23 AM Francesca Palombini <francesca.palombini@ericsson.com> wrote:

Hi all,

=C2=A0

We have left enough time to let these PR being discu= ssed. According to the response on github and the threads in here, I think = it is time to merge: 14, 15, 19, 20. Authors, could you go on and merge the= se?


Thanks! I assume you me= an that the editors should merge these, since I don't have write access= .

Jeffrey

=C2=A0

Jim, would you be able to open an issue (or a mail t= hread)/ propose a change to fix the problem with the original language you = mention below?

=C2=A0

17 and 18 are still under discussion.<= /p>

=C2=A0

Note that some new PR have been opened (24, 25): dis= cussion is going on (github issues and mailing list), so make sure to voice= your opinion if you have any.

=C2=A0

Thanks to everybody who is participating!
Francesca

From: Jim Schaad <ietf@augustcellars.com>
Sent: den 26 maj 2018 00:20
To: 'Jeffrey Yasskin' <jyasskin@chromium.org>; Francesca Palombini= <= francesca.palombini@ericsson.com>
Cc: cbor@ietf.org= ; draft-ietf-cbor-7049bis@ietf.org; cbor-chairs@ietf.org
Subject: RE: [Cbor] Progressing work on draft-ietf-cbor-7049bis

=C2=A0

=C2=A0

=C2=A0

From: CBOR <cbor-bounces@ietf.org> On Behalf Of Jeffrey Yasskin
Sent: Friday, May 25, 2018 11:19 AM
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: cbor@ietf.org= ; draft-ietf-cbor-7049bis@ietf.org; cbor-chairs@ietf.org
Subject: Re: [Cbor] Progressing work on draft-ietf-cbor-7049bis

=C2=A0

My impression of the state of these PRs is:

=C2=A0

On Thu, Apr 26, 2018 at 7:14 AM Francesca Palombini = <= francesca.palombini@ericsson.com> wrote:

Hi all,

=C2=A0

In order to progress the draft, I=E2=80=99d like you= to take a look at Jeffrey=E2=80=99s proposals (quoted selected text from h= is mail below).

=C2=A0

Only PR17 has gotten one comment so far (let=E2=80= =99s discuss it further). Note that the PR were submitted more than a month= ago, if I hear no objections to them before the 11th of May, we=E2=80=99ll ask the editors to go ahead and merge them, so pleas= e take a look and speak up. Even a =E2=80=9C+1=E2=80=9D is useful.

=C2=A0

Big PR:

https://github.= com/cbor-wg/CBORbis/pull/17 has a lot of changes to define which kinds of CBOR parsers need to d= etect which errors in the encoded data, and which errors are recoverable.

=C2=A0

Still under discussion.

=C2=A0

https://github.= com/cbor-wg/CBORbis/pull/18 defines when the known kinds of tagged items are valid.=C2=A0

=C2=A0

The only objection misunderstood which text I remove= d, so this is probably ok to merge. Its description of tag 35 is still some= what ambiguous because PCRE and ECMAScript have different sets of valid reg= ular expressions, but I think it's still an improvement over what was there before.

=C2=A0

[JLS] I have no real opinion on this set of changes<= u>

=C2=A0

Minor PR:

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

=C2=A0

No comments at all, and this is probably uncontrover= sial.

=C2=A0

https://github.= com/cbor-wg/CBORbis/pull/19 fixes an example of Javascript being unable to distinguish strings from numbers when they&#= 39;re used as map keys

=C2=A0

One comment from Jim led to me updating the ECMAScri= pt reference.

=C2=A0

[JLS] My only problem with this has more to do with = the original language =C2=A0than with any changes (the problem I have is st= ill there).=C2=A0 I would not block anything on the problem I have as it is= probably just me.

=C2=A0

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

=C2=A0

Jim wondered whether declaring a map ordering to be = an error constitutes a change to the semantics based on ordering, and I'= ;ve changed the text to be clear that it's allowed.

=C2=A0

[JLS] No problems with this update

=C2=A0

Thanks,

Jeffrey=C2=A0

--000000000000892fe0056d5c68ed-- From nobody Wed May 30 09:06:38 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44C12EB6B for ; Wed, 30 May 2018 09:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF0wE94mk_M6 for ; Wed, 30 May 2018 09:06:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC2712EB50 for ; Wed, 30 May 2018 09:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1527696394; x=1559232394; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vOE79yI4QvHfA0zrIUMiq9NkprOsunRc9lHdrwD4KaY=; b=fYvgcs1m/+3S16HgXqt8OiU/TBHkvYuLBDkVivyZy53L7oA3i0E0BKVM a+UiowFBG7IXxx4izsDgYy3bJmFoP/TlA1w+jYE8VdvG6It1cwst8gvlN lkL+W+EDT/DlWXSCGXKUSi0RhWrrBqAVflqKuf05RZKlP4WMT7IS0ypiJ U=; X-IronPort-AV: E=Sophos;i="5.49,461,1520924400"; d="scan'208";a="438519302" Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by wolverine02.qualcomm.com with ESMTP; 30 May 2018 09:06:34 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8909"; a="208502930" Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/AES256-SHA; 30 May 2018 09:06:34 -0700 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 30 May 2018 09:06:33 -0700 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Wed, 30 May 2018 09:06:33 -0700 From: Laurence Lundblade To: "cbor@ietf.org" Thread-Topic: Canonical CBOR Thread-Index: AQHT+DAt/gk8uO725UeTARiGORDsvg== Date: Wed, 30 May 2018 16:06:32 +0000 Message-ID: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="utf-8" Content-ID: <4C78277572E0274486A6EC2D9EA12E47@qualcomm.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 16:06:37 -0000 VG8gYmUgYSBiaXQgZGlyZWN0IGhlcmUsIGNhbm9uaWNhbCBDQk9SIHNlZW1zIG9ubHkgYWJvdXQg Mi8zIGJha2VkIHRvIG1lLiBJIGhhdmUgYSBjb3VwbGUgb2YgaWRlYXMgb24gd2hhdCB0byBkbyBh Ym91dCBhbmQgbWF5IHZvbHVudGVlciB0byB3cml0ZSBzb21lIHRleHQsIGJ1dCBmaXJzdCBJIHdh bnQgdG8gYXNrIGFib3V0IHVzZSBjYXNlcyBmb3IgaXQuICBJ4oCZdmUgc2VlbiBzb21lIGRlc2Ny aWJlZCwgYnV0IHRoZXkgcmVhbGx5IGFyZW7igJl0IGNvbXBlbGxpbmcgdG8gbWUuDQoNCkkgdGhp bmsgdGhlIGltcG9ydGFudCBxdWVzdGlvbiBpcyB0aGlzOiBoYXMgYW55b25lIGFjdHVhbGx5IGlt cGxlbWVudGVkIGl0IGFuZCBwdXQgaXQgdG8gdXNlPyANCg0KT25lIHVzZSBjYXNlIG1lbnRpb25l ZCBpcyB0byBiZSBhYmxlIHRvIHJlY29uc3RydWN0IHRoZSBlbmNvZGVkIENCT1IgdG8gdmVyaWZ5 IGEgc2lnbmF0dXJlIGFmdGVyIGRlY29kaW5nLiBJZiB0aGF0IGlzIHRvIGJlIHN1cHBvcnRlZCB3 ZSBzaG91bGQgc3BlY2lmeSBjYW5vbmljYWwgZW5jb2RpbmcgZm9yIGV2ZXJ5IHR5cGUgaW4gdGhl IFJGQy4gUmlnaHQgbm93IHRoZXJlIGlzIGEgZ29vZCBzcGVjaWZpY2F0aW9uIGZvciBzb21lIHR5 cGVzIChpbnRlZ2VycyksIGJ1dCBvbmx5IHN1Z2dlc3Rpb25zIGZvciBvdGhlcnMgKGZsb2F0aW5n IHBvaW50KS4gDQoNCkFub3RoZXIgdXNlIGNhc2UgaXMgdGhhdCBtYXAgc29ydGluZyBhbGxvd3Mg Zm9yIGZhc3QgZGV0ZWN0aW9uIG9mIGR1cGxpY2F0ZSBsYWJlbHMuIEkgZG9u4oCZdCBrbm93IHdo eSBkdXBsaWNhdGUgZGV0ZWN0aW9uIGlzIG5lZWRlZC4gSWYgeW91IGNhbuKAmXQgdHJ1c3QgdGhl IHNlbmRlciBhbmQvb3IgdHJhbnNwb3J0IHRvIG5vdCBhZGQgZHVwbGljYXRlcywgeW91IGNhbuKA mXQgcmVhbGx5IHRydXN0IHRoZW0gdG8gbm90IG1ha2Ugb3RoZXIgd29yc2UgbWlzdGFrZXMuIA0K DQpCdXQgdGhlIHJlYWwgcXVlc3Rpb24gaXMgYWJvdXQgaW1wbGVtZW50YXRpb25zLiBJZiBub3cg b25lIGhhcyBpbXBsZW1lbnRlZCBpbiB0aGUgeWVhcnMgdGhhdCA3MDQ5IGhhcyBiZWVuIGFyb3Vu ZCBpdCBzZWVtcyBxdWVzdGlvbmFibGUuDQoNCg0KSGVyZeKAmXMgYSBmZXcgaWRlYXMgZm9yIHdo YXQgdG8gZG86DQoNCiMxIFJlcXVpcmUgYWxsIGludGVnZXJzIGFuZCBsZW5ndGhzIHRvIGFsd2F5 cyBiZSBpbiBzaG9ydGVzdCBmb3JtIGFuZCBhbHdheXMgdGhlIHNhbWUuIERvIHRoZSBzYW1lIGZv ciBmbG9hdGluZyBwb2ludCwgZGF0ZXMgYW5kIGFzIG1hbnkgb3RoZXIgb2YgdGhlIHR5cGVzIGRl ZmluZWQgaW4gdGhlIHNwZWMgYXMgcG9zc2libGUuICBGb3IgYSBsb3Qgb2YgZGF0YSB0eXBlcywg dGhpcyBpcyBub3QgdGhhdCBoYXJkIHRvIGltcGxlbWVudCBhbmQgaXQgZWxpbWluYXRlcyBhIHZh cmlhYmlsaXR5IGluIHRoZSBzcGVjIHRoYXQgc2VlbXMgdW5uZWNlc3NhcnkuIFRoZW4geW91IGRv buKAmXQgaGF2ZSB0byBkZWZpbmUgYSBjYW5vbmljYWwgZm9ybWF0IGZvciB0aGVzZSB0eXBlcy4g VGhleSBhcmUgYWx3YXlzIGNhbm9uaWNhbC4NCg0KIzIgSWYgbm90ICMxLCB0aGVuIG1ha2UgYSBj bGVhciBzdWJzZWN0aW9uIG9mIHRoZSBkb2N1bWVudCB0aGF0IHNoYXJwbHkgZGVmaW5lcyB0aGUg Y2Fub25pY2FsIGZvcm1hdCBmb3IgYWxsIGRhdGEgdHlwZXMgdGhhdCBoYXZlIG11bHRpcGxlIHJl cHJlc2VudGF0aW9ucy4gVGhpcyBpcyBzcGVjaWFsbHkgY2FsbGVkIOKAnENhbm9uaWNhbCBDQk9S 4oCdIGFuZCBhbnlvbmUgY2xhaW1pbmcgdG8gaW1wbGVtZW50IGl0LCBNVVNUIGltcGxlbWVudCBh bGwgYXNwZWN0cyBvZiBpdC4gIFdlIGFsc28gaGlnaGx5IHJlY29tbWVuZGVkIHRoYXQgZXZlcnkg aW1wbGVtZW50YXRpb24gdXNlIGl0LiAgTW92ZSB0aGlzIHRvIHNlY3Rpb24gMyBzbyBpdCBpcyBu b3QgaW4gdGhlIHJlY29tbWVuZGF0aW9ucyBmb3IgY3JlYXRpbmcgcHJvdG9jb2xzLiBMZWF2ZSB0 aGUgc29ydGluZyBvcmRlciBhbmQgdXNlIG9mIGRlZmluaXRlIGxlbmd0aHMgcmVxdWlyZW1lbnRz IG91dCBvZiB0aGlzIHNlY3Rpb24gYmVjYXVzZSB0aGV5IGFyZSBjb3N0bHkgdG8gaW1wbGVtZW50 Lg0KDQojMyBSZW5hbWUgc2VjdGlvbiA0LjkgdG8gc29tZXRoaW5nIGxpa2Ug4oCccmVjb21tZW5k YXRpb25zIGZvciB1bmlmb3JtIENCT1LigJ0gKG9yIOKAnGludmFyaWFudOKAnSwgb3Ig4oCcY29u c2lzdGVudOKAnSBDQk9SKS4gVGhpcyB0ZXh0IGlzIG5vbi1ub3JtYXRpdmUgcmVjb21tZW5kYXRp b25zIG9ubHkuIFRoZSBzb3J0aW5nIG9yZGVyIGNhbiBiZSBwYXJ0IG9mIHRoaXMuIA0KDQpCYXNp Y2FsbHksIHRoZSBsZXNzIHdvcmsgd2UgbGVhdmUgdG8gQ0JPUiBwcm90b2NvbCBkZXNpZ25lcnMs IHRoZSBiZXR0ZXIuIEl04oCZbGwgYmUgZWFzaWVyIGZvciBwcm90b2NvbCBkZXNpZ25lcnMgdG8g ZG8gdGhlcmUgd29yaywgdGhleeKAmWxsIGdldCBpdCByaWdodCBtb3JlIG9mdGVuIGFuZCB0aGVy ZeKAmWxsIGJlIGxlc3MgaW50ZXJvcCBwcm9ibGVtcy4NCg0KDQpMYXN0LCBJIHRoaW5rIHRoZSBu YW1lcyDigJxDYW5vbmljYWwgRW5jb2RlZCBDQk9S4oCdIGFuZCDigJxTdHJpY3QgQ0JPUiBEZWNv ZGluZ+KAnSB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bC4gDQoNCkxMDQoNCg0KDQoNCg0KDQoNCg== From nobody Wed May 30 11:13:07 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55912E9D7 for ; Wed, 30 May 2018 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.952 X-Spam-Level: X-Spam-Status: No, score=-9.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbMzLQKKVhYK for ; Wed, 30 May 2018 11:12:53 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C2212DA24 for ; Wed, 30 May 2018 11:12:53 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id k17-v6so2016545ita.0 for ; Wed, 30 May 2018 11:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mRdtWkoe5zvkzU9smJYkUKVGgbQMK0mtlEWPoaWp10c=; b=Zlcf/Z2xOVL5fIjJYGCt+LNAAiYbDVPYSTGdXg2XDZJbDSSPe8NKu8ChvaGi6vkPs3 u3Fj/nOWaMLtU+FrHzNN1Ohs/1JQQREwxNFxI4ilEocQ3jTctOU8sMH8zD/Akzc+TUIt TyssMMzuytbg0O1jJ56w9EXXZrApJUpTMk4a0= 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=mRdtWkoe5zvkzU9smJYkUKVGgbQMK0mtlEWPoaWp10c=; b=MrFTE/MYTavj13eIsz7vzYNrX9+enRnjNZb4azVzFs7TYD1F1uJ8t+41ExYyAFRMk4 a3Bflk7o/5OS16IOJHYbbRmdlst17Sdv3SXqMmLuhdQkATFD4Owu7PscVzQ3cdsz87ca gvDC5s2Xh15BUsIA/jeAIh1zuuxBPcGPP964BXYFmoovYT+m5QOwmYj0Jz0gWViesDyN AgrM34vaek8EAf1mXxQMKt4yK5JNgxE2G7609/u3Iln6jS7+UIGqtj7LHTcNDXd5T4ql mS7TRo5s3Ljq0Z9OwKz6GELtKjOYrBJ8asFFGRohQKOGlpnHigir8vbPzLxLk4PzIHTT /ryQ== X-Gm-Message-State: ALKqPweZiVONdJzSao5QSMZgzJ/P6EOkV0VfhcViLVT+dK/xkv2O3CdN zsBgayBjguYZbPAgve/0o4UQVUSd5BY3+kso7tA3bw== X-Google-Smtp-Source: ADUXVKI0e+CArp5J05wFE2KflBX75HL15vk0fR6MGyH/6w2ARFaac/QViAiNg+59U/lVmvdQY8Pexf6HFebR5OYOWL4= X-Received: by 2002:a24:354b:: with SMTP id k72-v6mr2764762ita.106.1527703972345; Wed, 30 May 2018 11:12:52 -0700 (PDT) MIME-Version: 1.0 References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> In-Reply-To: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> From: Jeffrey Yasskin Date: Wed, 30 May 2018 11:12:38 -0700 Message-ID: To: llundbla@qti.qualcomm.com Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000988c8c056d704cc8" Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 18:13:01 -0000 --000000000000988c8c056d704cc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the prod to try to explain this better. On Wed, May 30, 2018 at 9:06 AM Laurence Lundblade < llundbla@qti.qualcomm.com> wrote: > To be a bit direct here, canonical CBOR seems only about 2/3 baked to me. > I have a couple of ideas on what to do about and may volunteer to write > some text, but first I want to ask about use cases for it. I=E2=80=99ve = seen some > described, but they really aren=E2=80=99t compelling to me. > > I think the important question is this: has anyone actually implemented i= t > and put it to use? https://cs.chromium.org/chromium/src/components/cbor/cbor_reader.h only parses (a subset of) CBOR matching the core canonicalization requirements. https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authent= icator-protocol-v2.0-id-20180227.html#ctap2-canonical-cbor-encoding-form requires non-canonical encodings to be rejected. One use case mentioned is to be able to reconstruct the encoded CBOR to > verify a signature after decoding. If that is to be supported we should > specify canonical encoding for every type in the RFC. Right now there is = a > good specification for some types (integers), but only suggestions for > others (floating point). > It's not obvious that verifying signatures is a good use for canonicalization (even though I keep listing it as a possible use), but in protocols that want to do it, the protocol is responsible to specify the unique bytes that encode any semantic object that can appear in the protocol. This is why https://cbor-wg.github.io/CBORbis/#rfc.section.4.9 defines "core canonicalization requirements" instead of "canonical CBOR". Another use case is that map sorting allows for fast detection of duplicate > labels. I don=E2=80=99t know why duplicate detection is needed. If you ca= n=E2=80=99t trust > the sender and/or transport to not add duplicates, you can=E2=80=99t real= ly trust > them to not make other worse mistakes. > We have to code expecting the sender to make any and all mistakes (sometimes maliciously). If we don't prohibit duplicates, we have to specify whether the first or last value "wins". If we do prohibit them, then that's one bit of parser variation we don't need to worry about. All the other possible mistakes are still on the table, of course. See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03. Here=E2=80=99s a few ideas for what to do: > > #1 Require all integers and lengths to always be in shortest form and > always the same. Do the same for floating point, dates and as many other = of > the types defined in the spec as possible. For a lot of data types, this > is not that hard to implement and it eliminates a variability in the spec > that seems unnecessary. Then you don=E2=80=99t have to define a canonical= format > for these types. They are always canonical. > Carsten prefers this representation of floating point, but the folks implementing FIDO hardware devices hate the idea of having to select between floating-point formats based on an item's value. There's some benefit in allowing integers to be in non-shortest form, in that a serializer can put a long placeholder integer in the byte stream, and then update it to its final value after writing some extra data. Despite this tradeoff, I wouldn't personally object if CBOR itself always required integers to be in shortest form. Since RFC7049 has been around for a while, this would probably require a survey of implementations to see if any actually take advantage of the flexibility. #2 If not #1, then make a clear subsection of the document that sharply > defines the canonical format for all data types that have multiple > representations. This is specially called =E2=80=9CCanonical CBOR=E2=80= =9D and anyone > claiming to implement it, MUST implement all aspects of it. We also high= ly > recommended that every implementation use it. Move this to section 3 so = it > is not in the recommendations for creating protocols. Leave the sorting > order and use of definite lengths requirements out of this section becaus= e > they are costly to implement. > This isn't sufficient to call the result "canonical", because a protocol may define multiple ways to represent something. For example, in Carsten's idea of an automatic JSON->CBOR converter, the result of converting "deadbeef" could be either a text string or the byte string h'75E69D6DE79F' wrapped in tag 22. Also, if a map can be sorted in two different ways, neither is canonical. #3 Rename section 4.9 to something like =E2=80=9Crecommendations for unifor= m CBOR=E2=80=9D > (or =E2=80=9Cinvariant=E2=80=9D, or =E2=80=9Cconsistent=E2=80=9D CBOR). T= his text is non-normative > recommendations only. The sorting order can be part of this. Basically, the less work we leave to CBOR protocol designers, the better. > It=E2=80=99ll be easier for protocol designers to do there work, they=E2= =80=99ll get it > right more often and there=E2=80=99ll be less interop problems. > > > Last, I think the names =E2=80=9CCanonical Encoded CBOR=E2=80=9D and =E2= =80=9CStrict CBOR > Decoding=E2=80=9D would be really helpful. > Yep, https://cbor-wg.github.io/CBORbis/#strict-mode isn't clear that "Strict Mode" applies only to decoders. It's also not precise enough to write just "use strict mode" in the definition of a decoder and be sure you'll get the same results from all decoders. Jeffrey --000000000000988c8c056d704cc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the prod to try= to explain this better.

O= n Wed, May 30, 2018 at 9:06 AM Laurence Lundblade <llundbla@qti.qualcomm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">To be a bit direct here, c= anonical CBOR seems only about 2/3 baked to me. I have a couple of ideas on= what to do about and may volunteer to write some text, but first I want to= ask about use cases for it.=C2=A0 I=E2=80=99ve seen some described, but th= ey really aren=E2=80=99t compelling to me.

I think the important question is this: has anyone actually implemented it = and put it to use?=C2=A0
=C2=A0

One use case mentioned is to be able to reconstruct the encoded CBOR to ver= ify a signature after decoding. If that is to be supported we should specif= y canonical encoding for every type in the RFC. Right now there is a good s= pecification for some types (integers), but only suggestions for others (fl= oating point).

It's not obvious th= at verifying signatures is a good use for canonicalization (even though I k= eep listing it as a possible use), but in protocols that want to do it, the= protocol is responsible to specify the unique bytes that encode any semant= ic object that can appear in the protocol. This is why=C2=A0https://cbor-wg.github.io/C= BORbis/#rfc.section.4.9 defines "core canonicalization requirement= s" instead of "canonical CBOR".

Another use case is that map sorting allows for fast detection of duplicate= labels. I don=E2=80=99t know why duplicate detection is needed. If you can= =E2=80=99t trust the sender and/or transport to not add duplicates, you can= =E2=80=99t really trust them to not make other worse mistakes.

We have to code expecting the sender to make any a= nd all mistakes (sometimes maliciously). If we don't prohibit duplicate= s, we have to specify whether the first or last value "wins". If = we do prohibit them, then that's one bit of parser variation we don'= ;t need to worry about. All the other possible mistakes are still on the ta= ble, of course. See also=C2=A0https://tools.ietf.org/html/draft-thomson-post= el-was-wrong-03.

Here=E2=80=99s a few ideas for what to do:

#1 Require all integers and lengths to always be in shortest form and alway= s the same. Do the same for floating point, dates and as many other of the = types defined in the spec as possible.=C2=A0 For a lot of data types, this = is not that hard to implement and it eliminates a variability in the spec t= hat seems unnecessary. Then you don=E2=80=99t have to define a canonical fo= rmat for these types. They are always canonical.

<= /div>
Carsten prefers this representation of floating point, but the fo= lks implementing FIDO hardware devices hate the idea of having to select be= tween floating-point formats based on an item's value.

There's some benefit in allowing integers to be in non-shortes= t form, in that a serializer can put a long placeholder integer in the byte= stream, and then update it to its final value after writing some extra dat= a. Despite this tradeoff, I wouldn't personally object if CBOR itself a= lways required integers to be in shortest form. Since RFC7049 has been arou= nd for a while, this would probably require a survey of implementations to = see if any actually take advantage of the flexibility.

=
#2 If not #1, then make a clear subsection of the document that sharply def= ines the canonical format for all data types that have multiple representat= ions. This is specially called =E2=80=9CCanonical CBOR=E2=80=9D and anyone = claiming to implement it, MUST implement all aspects of it.=C2=A0 We also h= ighly recommended that every implementation use it.=C2=A0 Move this to sect= ion 3 so it is not in the recommendations for creating protocols. Leave the= sorting order and use of definite lengths requirements out of this section= because they are costly to implement.

= This isn't sufficient to call the result "canonical", because= a protocol may define multiple ways to represent something. For example, i= n Carsten's idea of an automatic JSON->CBOR converter, the result of= converting "deadbeef" could be either a text string or the byte = string h'75E69D6DE79F' wrapped in tag 22.

= Also, if a map can be sorted in two different way= s, neither is canonical.

#3 Rename section 4.9 to something like =E2=80=9Crecommendations for unifor= m CBOR=E2=80=9D (or =E2=80=9Cinvariant=E2=80=9D, or =E2=80=9Cconsistent=E2= =80=9D CBOR). This text is non-normative recommendations only. The sorting = order can be part of this.=C2=A0

Basically, the less work we leave to CBOR protocol designers, the better. I= t=E2=80=99ll be easier for protocol designers to do there work, they=E2=80= =99ll get it right more often and there=E2=80=99ll be less interop problems= .


Last, I think the names =E2=80=9CCanonical Encoded CBOR=E2=80=9D and =E2=80= =9CStrict CBOR Decoding=E2=80=9D would be really helpful.
=

Yep,=C2=A0https://cbor-wg.github.io/CBORbis/#strict-mode isn't = clear that "Strict Mode" applies only to decoders. It's also = not precise enough to write just "use strict mode" in the definit= ion of a decoder and be sure you'll get the same results from all decod= ers.

Jeffrey
--000000000000988c8c056d704cc8-- From nobody Wed May 30 12:11:05 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEDB12EA8E for ; Wed, 30 May 2018 12:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFZWP9IBys4L for ; Wed, 30 May 2018 12:10:57 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD5F12E8EE for ; Wed, 30 May 2018 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w4UJAlX9026984; Wed, 30 May 2018 21:10:47 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40x0YL6G1nzDXY2; Wed, 30 May 2018 21:10:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> Date: Wed, 30 May 2018 21:10:46 +0200 Cc: "cbor@ietf.org" X-Mao-Original-Outgoing-Id: 549400244.3210649-df8826e4efe0793fb8e90d2a547b2830 Content-Transfer-Encoding: quoted-printable Message-Id: <96D1A695-3152-4391-B0F8-7F4620A83A68@tzi.org> References: <6F0291FD-A556-4541-80A0-2429ABF60AC0@qti.qualcomm.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] Canonical CBOR X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 19:11:01 -0000 Hi Laurence, thank you for bringing this subject up again. In 2013, we knew what we were up to when we wrote the original section = 3.9 of RFC 7049. Essentially, canonicalization (14n) is a mine field where the only way = to win is to not play. However, we got a few things right, I think: (1) we acknowledged that c14n is to a certain extent = application-specific. So the RFC gives some guidance, but does not = define a single hard and fast set of rules. (2) the serialization provides little intrinsic incentive for gratuitous = variation. Apart from definite vs. indefinite lengths (which is an = example of something that depends on application requirements), the = obvious rule to use the shortest of several possible encodings is = natural and easy to implement. [One design alternative, to only ever = allow the shortest encoding, is problematic for some other = applications.] Implementations already do this naturally (except = sometimes for floating point =E2=80=94 implementers of serialization = layers often know little about floating point and are rightfully scared = by it. That=E2=80=99s why we have the example code in the appendix=E2=80=A6= and it is easy to do exhaustive testing at least for binary16!). We also got one thing extremely wrong: (A) the canonical ordering for keys based on lengths first, then = byte-wise lexicographical order, is violating the principle of least = surprise and poses some performance disadvantages. This probably should = be fixed to pure byte-wise lexicographical order. Applications that = already have decided to use the existing map order guidance can do that = by invoking (1) above. So what are the use cases? Signing information expressed at the data = model level is often given as one, but it is not very convincing. What = I consider much more interesting is to be able to do byte-wise = comparison of instances to establish a certain degree of data model = level equality/inequality. This is really useful for testing and for = matching information in a database. Several of the 50 implementations of CBOR listed at cbor.io do some form = of c14n, sometimes as an add-on. (E.g., for cbor-ruby, there is a = separate gem cbor-canonical that provides canonical encoding. There is = no decode checker =E2=80=94 you check by canonical-encoding again and = then doing a bytewise comparison.) I never got around to collecting = feature lists for the implementations on cbor.io, so I don=E2=80=99t = know how many of them do canonical. We discussed c14n in some detail at IETF 101. Please search for =E2=80=9Cc14n=E2=80=9D in: https://datatracker.ietf.org/meeting/101/materials/minutes-101-cbor-00 and read up to =E2=80=9Cimplementation matrix=E2=80=9D. While we didn=E2=80=99t make a final determination at the meeting, it = seems to me that the best way forward is to keep c14n at the =E2=80=9Cprop= osed standard=E2=80=9D level, by splitting it out to a separate = document, while the rest of CBOR goes to Internet Standard. This also = reflects the lower levels of implementation experience we have with = c14n, and the desire to fix the map order. > Here=E2=80=99s a few ideas for what to do: >=20 > #1 Require all integers and lengths to always be in shortest form and = always the same. We already do this for c14n. (Do you mean to always require this? Not = so sure about that.) > Do the same for floating point, (But only weakly so for floating point.) > dates and as many other of the types defined in the spec as possible. =20= These often have way more application semantics than you can handle in a = generic canonicalizer. Try canonicalizing URIs, Regexps, etc. Do you canonicalize RFC 3339 = dates to UTC? I think we have to be open about the limitations of what can be done = here. > For a lot of data types, this is not that hard to implement and it = eliminates a variability in the spec that seems unnecessary. Then you = don=E2=80=99t have to define a canonical format for these types. They = are always canonical. I sure like that approach. > #2 If not #1, then make a clear subsection of the document that = sharply defines the canonical format for all data types that have = multiple representations. This is specially called =E2=80=9CCanonical = CBOR=E2=80=9D and anyone claiming to implement it, MUST implement all = aspects of it. We also highly recommended that every implementation use = it. Move this to section 3 so it is not in the recommendations for = creating protocols. That would be the separate document proposed above? > Leave the sorting order and use of definite lengths requirements out = of this section because they are costly to implement. Er, now you lost me. > #3 Rename section 4.9 to something like =E2=80=9Crecommendations for = uniform CBOR=E2=80=9D (or =E2=80=9Cinvariant=E2=80=9D, or = =E2=80=9Cconsistent=E2=80=9D CBOR). This text is non-normative = recommendations only. The sorting order can be part of this. =E2=80=9CConsistent CBOR=E2=80=9D sounds good to me. (As a name for the = new version with the fixed map sorting order=E2=80=A6) > Basically, the less work we leave to CBOR protocol designers, the = better. It=E2=80=99ll be easier for protocol designers to do there work, = they=E2=80=99ll get it right more often and there=E2=80=99ll be less = interop problems. I can=E2=80=99t argue with that. Prematurely nailing down details can = also be very costly, though. > Last, I think the names =E2=80=9CCanonical Encoded CBOR=E2=80=9D and = =E2=80=9CStrict CBOR Decoding=E2=80=9D would be really helpful.=20 With what semantics? Gr=C3=BC=C3=9Fe, Carsten