From nobody Sun Nov 6 14:36:18 2016 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 251F8129702 for ; Sun, 6 Nov 2016 14:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.517 X-Spam-Level: X-Spam-Status: No, score=-8.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 FC1sWsw56y0L for ; Sun, 6 Nov 2016 14:36:14 -0800 (PST) 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 D3B241296F3 for ; Sun, 6 Nov 2016 14:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1478471774; x=1510007774; h=from:to:subject:date:message-id:mime-version; bh=xuNwHW4yWOD3aqV1N/u+FK4H7yjzxIvV+NsA5S+QSHk=; b=YOZOK2o/noTPMNfMxOTo2X1pfhyoTX0uvdB0cnD9jfDW62XSXJWcshO7 7yHudgG/Hxw1Wv+SQk1tNtubH0j11Je2FrLWySs3SNYxbzxIcBHDCU6XK UeO3xYLluoP0phXLcDZ9JRBatfv+iS5LNsDAy8TT7rSibNn591U8CWBK5 g=; X-IronPort-AV: E=Sophos;i="5.31,603,1473145200"; d="scan'208,217";a="333099710" Received: from unknown (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine02.qualcomm.com with ESMTP; 06 Nov 2016 14:36:14 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8341"; a="808294567" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Nov 2016 14:36:14 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 6 Nov 2016 14:36:13 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Sun, 6 Nov 2016 14:36:13 -0800 From: "Lundblade, Laurence" To: "cbor@ietf.org" Thread-Topic: Simple value clarification Thread-Index: AQHSOH4tiybdq58K7kitqwLp+uaE9w== Date: Sun, 6 Nov 2016 22:36:13 +0000 Message-ID: <025B0837-F7BA-47F4-B6A2-02CE9D318F7B@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: multipart/alternative; boundary="_000_025B0837F7BA47F4B6A202CE9D318F7Bqtiqualcommcom_" MIME-Version: 1.0 Archived-At: Subject: [Cbor] Simple value clarification X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 22:36:17 -0000 --_000_025B0837F7BA47F4B6A202CE9D318F7Bqtiqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Is there a difference between these two ways of encoding simple values? 1) true, false=85 encoded as f4, f5.. f7 2) true false=85 encoded as f8 14, f8 15=85 f8 17 - Table 2 implies they should be the same to me - CBOR playground doesn=92t consider them the same outputting "simple(20)= =94 for input f8 14 - The parenthetical in section 2.3 implies representation 2) is shouldn=92t= be used because it is confusing, but doesn=92t explicitly forbid it My choice of resolution would be: true, false=85 are always encoded as f4=85 f7, never as f8 14=85 f8 17 encodings f8 00 ... f8 1f are not allowed and are malformed cbor upon which= a parser will error out. If you want to encode a simple value less than 24= , use of e0 =85 f7 is required. The encodings of unassigned simple values available to extend CBOR are: 0=85 19 which must be encoded as e0 =85 f3 32 =85 255 which must be encoded as f8 20 =85 f8 ff LL --_000_025B0837F7BA47F4B6A202CE9D318F7Bqtiqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0C505077B75FA048A045164A7A4D58A5@qualcomm.com> Content-Transfer-Encoding: quoted-printable Is there a difference between these two ways of encoding simple values?
1) true, false=85 encoded as f4, f5.. f7
2) true false=85 encoded as  f8 14, f8 15=85 f8 17

- Table 2 implies they should be the same to me
- CBOR playground doesn=92t consider them the same outputting "si= mple(20)=94 for input f8 14
- The parenthetical in section 2.3 implies representation 2) is should= n=92t be used because it is confusing, but doesn=92t explicitly forbid it

My choice of resolution would be:

true, false=85 are always encoded as f4=85 f7, never as f8 14=85 f8 17=

encodings f8 00 ... f8 1f are not allowed and are malformed cbor upon = which a parser will error out. If you want to encode a simple value less th= an 24, use of e0 =85 f7 is required.

The encodings of unassigned simple values available to extend CBOR are= :
0=85 19 which must be encoded as e0 =85 f3
32 =85 255 which must be encoded as f8 20 =85 f8 ff

LL

--_000_025B0837F7BA47F4B6A202CE9D318F7Bqtiqualcommcom_-- From nobody Sun Nov 6 16:56:20 2016 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 50E411299B3 for ; Sun, 6 Nov 2016 16:56:19 -0800 (PST) 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 MIW8wcCWbs31 for ; Sun, 6 Nov 2016 16:56:17 -0800 (PST) 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 965ED1299AF for ; Sun, 6 Nov 2016 16:56:16 -0800 (PST) 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 uA70uDDp024668; Mon, 7 Nov 2016 01:56:13 +0100 (CET) Received: from [192.168.217.113] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tBvC12M33z7ykn; Mon, 7 Nov 2016 01:56:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <025B0837-F7BA-47F4-B6A2-02CE9D318F7B@qti.qualcomm.com> Date: Mon, 7 Nov 2016 01:56:12 +0100 X-Mao-Original-Outgoing-Id: 500172972.69297-fd39d8a4286de37c8ba80a42351fa254 Content-Transfer-Encoding: quoted-printable Message-Id: <37C53DF9-FF09-43F8-9ACF-8B1DAD26F0F8@tzi.org> References: <025B0837-F7BA-47F4-B6A2-02CE9D318F7B@qti.qualcomm.com> To: "Lundblade, Laurence" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Simple value clarification X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 00:56:19 -0000 Hi Laurence, thank you for your input! Here is my take: > Is there a difference between these two ways of encoding simple = values? > 1) true, false=E2=80=A6 encoded as f4, f5.. f7 > 2) true false=E2=80=A6 encoded as f8 14, f8 15=E2=80=A6 f8 17 Don=E2=80=99t do (2). > - Table 2 implies they should be the same to me That is on the data model level, where you don=E2=80=99t see the = difference. > - CBOR playground doesn=E2=80=99t consider them the same outputting = "simple(20)=E2=80=9D for input f8 14 That seems to be a bug in the tool*) =E2=80=94 it should reject that = value according to the text between Table 1 and Table 2. > - The parenthetical in section 2.3 implies representation 2) is = shouldn=E2=80=99t be used because it is confusing, but doesn=E2=80=99t = explicitly forbid it =E2=80=A6 only the values 32 to 255 are used. =E2=80=A6 sounds pretty normative to me (yes, we could have sprinkled a MUST = there). But maybe we should revisit that text to be clearer. > My choice of resolution would be: >=20 > true, false=E2=80=A6 are always encoded as f4=E2=80=A6 f7, never as f8 = 14=E2=80=A6 f8 17 Yes. > encodings f8 00 ... f8 1f are not allowed and are malformed cbor upon = which a parser will error out. If you want to encode a simple value less = than 24, use of e0 =E2=80=A6 f7 is required. Yes. > The encodings of unassigned simple values available to extend CBOR = are: > 0=E2=80=A6 19 which must be encoded as e0 =E2=80=A6 f3 > 32 =E2=80=A6 255 which must be encoded as f8 20 =E2=80=A6 f8 ff Exactly. Gr=C3=BC=C3=9Fe, Carsten *) interestingly, I just got another bug report for that tool=E2=80=A6 = Need to spend some quality time with it soon. From nobody Mon Nov 7 08:41:42 2016 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 81EFC129850 for ; Mon, 7 Nov 2016 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 ODfdgyNgrS83 for ; Mon, 7 Nov 2016 08:41:40 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B10612973D for ; Mon, 7 Nov 2016 08:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1478536900; x=1510072900; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z7Kf+nNb6ZJk9RSUnpa/a9GU8pdct7FcGQFDJkR7T8w=; b=FXDvtggS68gF71orio2eVCdp01sJVMLHAgKUibho+kxKo7jLGYERhtlP oIWntrwgdmaOzxDoZ3oeqDQcoKSNXqKT4uEFwAoFzCGMt7tsIZ4VHvozE /XoYv2dQC2kfK0uhwvXMAZPG4I7eudxsEBhWoBVYYjLttY2nsGhxBDUfD Q=; X-IronPort-AV: E=Sophos;i="5.31,606,1473145200"; d="scan'208";a="238108829" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by wolverine01.qualcomm.com with ESMTP; 07 Nov 2016 08:41:39 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8342"; a="1252296569" Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Nov 2016 08:41:39 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 7 Nov 2016 08:41:38 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Mon, 7 Nov 2016 08:41:39 -0800 From: "Lundblade, Laurence" To: Carsten Bormann Thread-Topic: [Cbor] Simple value clarification Thread-Index: AQHSOH4tiybdq58K7kitqwLp+uaE96DNOJcAgAEIJoA= Date: Mon, 7 Nov 2016 16:41:38 +0000 Message-ID: <286700D7-D26E-4083-9343-9419B77CB223@qti.qualcomm.com> References: <025B0837-F7BA-47F4-B6A2-02CE9D318F7B@qti.qualcomm.com> <37C53DF9-FF09-43F8-9ACF-8B1DAD26F0F8@tzi.org> In-Reply-To: <37C53DF9-FF09-43F8-9ACF-8B1DAD26F0F8@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Simple value clarification X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 16:41:41 -0000 Thanks for the confirmation. Seems worthy of errata for the RFC to me. Someone getting the wrong idea co= uld lead to an interop problem, particularly since cbor.me doesn=92t compla= in. LL On Nov 6, 2016, at 4:56 PM, Carsten Bormann wrote: > Hi Laurence, >=20 > thank you for your input! > Here is my take: >=20 >> Is there a difference between these two ways of encoding simple values? >> 1) true, false=85 encoded as f4, f5.. f7 >> 2) true false=85 encoded as f8 14, f8 15=85 f8 17 >=20 > Don=92t do (2). >=20 >> - Table 2 implies they should be the same to me >=20 > That is on the data model level, where you don=92t see the difference. >=20 >> - CBOR playground doesn=92t consider them the same outputting "simple(20= )=94 for input f8 14 >=20 > That seems to be a bug in the tool*) =97 it should reject that value acco= rding to the text between Table 1 and Table 2. >=20 >> - The parenthetical in section 2.3 implies representation 2) is shouldn= =92t be used because it is confusing, but doesn=92t explicitly forbid it >=20 > =85 only the values 32 to 255 are > used. =85 >=20 > sounds pretty normative to me (yes, we could have sprinkled a MUST there)= . > But maybe we should revisit that text to be clearer. >=20 >> My choice of resolution would be: >>=20 >> true, false=85 are always encoded as f4=85 f7, never as f8 14=85 f8 17 >=20 > Yes. >=20 >> encodings f8 00 ... f8 1f are not allowed and are malformed cbor upon wh= ich a parser will error out. If you want to encode a simple value less than= 24, use of e0 =85 f7 is required. >=20 > Yes. >=20 >> The encodings of unassigned simple values available to extend CBOR are: >> 0=85 19 which must be encoded as e0 =85 f3 >> 32 =85 255 which must be encoded as f8 20 =85 f8 ff >=20 > Exactly. >=20 > Gr=FC=DFe, Carsten >=20 > *) interestingly, I just got another bug report for that tool=85 Need to= spend some quality time with it soon. >=20 >=20 >=20 From nobody Sat Nov 26 19:08:51 2016 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 DA921129422 for ; Sat, 26 Nov 2016 19:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.498 X-Spam-Level: X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 HuFuuL9RpYhR for ; Sat, 26 Nov 2016 19:08:48 -0800 (PST) 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 CFC2E12949E for ; Sat, 26 Nov 2016 19:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1480216128; x=1511752128; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wf1sIzGzty9CS5tIGhD+7KEnYXaZT53att9FM0RSpys=; b=fmvaumdaeypA08yK0DI4sHbnQggQmx/eR3ejv7XklPYT6EeO/ddeO0wo tTJyIP1X3i2slx0Zp7IySebOxrhVvZ8RnkUzODT8qaNQc5egWM1tZTlxJ J80szjuwXj1nvGis8r39H4TWAR1as8agz1cH3BQu59WhX9u2fYWvbIzW7 4=; X-IronPort-AV: E=Sophos;i="5.31,703,1473145200"; d="scan'208";a="338604890" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([10.53.140.110]) by wolverine02.qualcomm.com with ESMTP; 26 Nov 2016 19:08:48 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8361"; a="1267946613" X-Amp-Result: CLEAN Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Nov 2016 19:08:48 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 26 Nov 2016 19:08:47 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Sat, 26 Nov 2016 19:08:47 -0800 From: "Lundblade, Laurence" To: "cbor@ietf.org" Thread-Topic: Tag for binary UUID? Thread-Index: AQHSSFuRI9Y18N3KS0OaZVbtgPVAiQ== Date: Sun, 27 Nov 2016 03:08:47 +0000 Message-ID: <75C3C937-8CEF-4112-AC29-13E40C3870AD@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-ID: <36A61B1D4BDD8C458CC138B76B4E181C@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Cbor] Tag for binary UUID? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 03:08:51 -0000 UUIDs (RFC 4122) have a base binary representation in 16 bytes and a much l= onger URN-oriented string representation. Seems like a type 6 tag would be = a good thing to label a UUID, especially the binary one, so that converters= to JSON know to do the string expansion. Does that seem right? LL From nobody Sat Nov 26 21:11:24 2016 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 7D9D51293EB for ; Sat, 26 Nov 2016 21:11:23 -0800 (PST) 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 KONdEyN_Y5u2 for ; Sat, 26 Nov 2016 21:11:21 -0800 (PST) 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 3FBB212711D for ; Sat, 26 Nov 2016 21:11:21 -0800 (PST) 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 uAR5BHjp001724; Sun, 27 Nov 2016 06:11:17 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tRHw56DnBz8KwS; Sun, 27 Nov 2016 06:11:17 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <75C3C937-8CEF-4112-AC29-13E40C3870AD@qti.qualcomm.com> Date: Sun, 27 Nov 2016 06:11:16 +0100 X-Mao-Original-Outgoing-Id: 501916275.886197-f3b539312dc0ec81deeca6a467032419 Content-Transfer-Encoding: quoted-printable Message-Id: <385F6975-CE17-4757-BEF0-88BEE9465C2D@tzi.org> References: <75C3C937-8CEF-4112-AC29-13E40C3870AD@qti.qualcomm.com> To: "Lundblade, Laurence" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "cbor@ietf.org" Subject: Re: [Cbor] Tag for binary UUID? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 05:11:23 -0000 On 27 Nov 2016, at 04:08, Lundblade, Laurence = wrote: >=20 > UUIDs (RFC 4122) have a base binary representation in 16 bytes and a = much longer URN-oriented string representation. Seems like a type 6 tag = would be a good thing to label a UUID, especially the binary one, so = that converters to JSON know to do the string expansion. Does that seem = right? Indeed. One of the nice things about CBOR tags as an extension = mechanism is that anyone can extend CBOR by just registering a tag. A = tag for binary UUIDs (37) has been registered a while ago: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml Spec is in: https://github.com/lucas-clemente/cbor-specs/blob/master/uuid.md Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 30 08:33:06 2016 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 7F15F129970; Wed, 30 Nov 2016 08:24:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148052309349.1739.12135189787179011013.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 08:24:53 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_charter-ietf-cbo?= =?utf-8?q?r-00-01=3A_=28with_COMMENT=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 16:31:07 -0000 X-List-Received-Date: Wed, 30 Nov 2016 16:31:07 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-cbor-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question out of curiosity: Is this wg intended to be a short term effort that will closed after publishing the named docs or is the plan to eventually add more stuff for long term maintenance or is that no clear yet? From nobody Wed Nov 30 10:09:09 2016 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 BB15E1298C3; Wed, 30 Nov 2016 10:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=BtfAthoZ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=papGp0w7 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 Com15xljfBzN; Wed, 30 Nov 2016 10:08:53 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4977D12969D; Wed, 30 Nov 2016 10:08:53 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A724F206E9; Wed, 30 Nov 2016 13:08:52 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 30 Nov 2016 13:08:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=tWYtRrsg4hx+sO0m6LM+Ea3n9+ g=; b=BtfAthoZGyDEB6K7/r8+uE9V6qVY90iN5ukrLOj+OUZFC/JzLageLlOoxu MtF3Oy0uef00FsFB7bRTk10f2+/utFVIfuTg7Wosx6rqCX3dMSnsshHeEoQRmjBN bXYGHRyHY7rAZMIHA2cHJ5QEHRI0Fx7HdUITpn6wUG1Nja5hA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=tW YtRrsg4hx+sO0m6LM+Ea3n9+g=; b=papGp0w7baiYSC3AC3HDXFXUN1G6dm7X6S DqcxPrqczmW0lyXd0Lc0cXK2zx46ImfB1vWbKDwWrl+/yBY8SI+dFaswBsdHkMjI 4vdGyxhtwknQpWdGhvmG2afVOMlx+sbHm6HuYF4apQHSpBcgCfLArZM0AV4FBfEy MDRhZywqQ= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7CB1B5A67D; Wed, 30 Nov 2016 13:08:52 -0500 (EST) Message-Id: <1480529332.3905780.804039489.051DCA55@webmail.messagingengine.com> From: Alexey Melnikov To: Mirja Kuehlewind , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-d142962a In-Reply-To: <148052309349.1739.12135189787179011013.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 18:08:52 +0000 References: <148052309349.1739.12135189787179011013.idtracker@ietfa.amsl.com> Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_charter-ietf-cbo?= =?utf-8?q?r-00-01=3A_=28with_COMMENT=29?= X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 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 Nov 2016 18:08:57 -0000 Hi Mirja, On Wed, Nov 30, 2016, at 04:24 PM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > charter-ietf-cbor-00-01: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-cbor/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Quick question out of curiosity: Is this wg intended to be a short term > effort that will closed after publishing the named docs or is the plan to > eventually add more stuff for long term maintenance or is that no clear > yet? I think the WG might recharter once initial milestones (listed in the charter) are done, but this is not guarantied at this point. Best Regards, Alexey From nobody Wed Nov 30 18:32:13 2016 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 919A3129407; Wed, 30 Nov 2016 18:32:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148055953156.9658.13531223337243553214.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 18:32:11 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Ben Campbell's Yes on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 02:32:11 -0000 Ben Campbell has entered the following ballot position for charter-ietf-cbor-00-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- What is meant by "RFC that can be used as a normative reference in a protocol specification"? If this means standards track or BCP--if so, why not say that? From nobody Wed Nov 30 19:48:28 2016 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 2FC4E129558; Wed, 30 Nov 2016 19:48:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 19:48:26 -0800 Archived-At: Cc: cbor@ietf.org, cbor-chairs@ietf.org Subject: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 03:48:26 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-cbor-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-cbor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given that "Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well." is describing a limited license for the working group for two proposals, I found myself wondering if there might be other proposals that are deemed useful and don't require significant new development, that the charter might allow without requiring rechartering. Maybe something like "Where these CBOR extensions, or other CBOR extension proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well." ? But if you want the charter to be tight in this respect, the current text is fine. From nobody Wed Nov 30 20:54:18 2016 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 27D85129A18; Wed, 30 Nov 2016 20:54:12 -0800 (PST) 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 ojzYjZvemSR2; Wed, 30 Nov 2016 20:54:10 -0800 (PST) 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 D3970129420; Wed, 30 Nov 2016 20:54:09 -0800 (PST) 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 uB14s0aU000237; Thu, 1 Dec 2016 05:54:00 +0100 (CET) Received: from [192.168.217.102] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3tTlLJ5Gx6z8LLV; Thu, 1 Dec 2016 05:54:00 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> Date: Thu, 1 Dec 2016 05:54:01 +0100 X-Mao-Original-Outgoing-Id: 502260841.118035-748fffc3b485cb7da203802f7af1e129 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3251) Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 04:54:12 -0000 Hi Spencer, On 1 Dec 2016, at 04:48, Spencer Dawkins = wrote: >=20 > or other CBOR extension proposals So far, the text has been careful to limit the scope to work that uses = existing extension points defined by RFC 7049 (for the two documents = cited. specifically, by defining CBOR tags). "or other CBOR extension = proposals=E2=80=9D might be taken to completely open Pandora=E2=80=99s = box here. But I agree that if something comes up that is of the same quality as = the two documents, the WG should be allowed to look into it. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Nov 30 22:13:33 2016 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 0F3CC129BD2; Wed, 30 Nov 2016 22:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kL852fRkJPfZ; Wed, 30 Nov 2016 22:13:28 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827F21299E9; Wed, 30 Nov 2016 22:13:28 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id a10so176426316ywa.3; Wed, 30 Nov 2016 22:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bGsePVhSWSTT/gjGm4Hf99qS9oJJC620C+9nA/2eb/M=; b=RcQI8xgvPcg152TAAyQAXQoG5jPb2cJ2N6ABLl2KqK1EyHGa1uRG/GApU8KzDK2Nnz bRKRmomDCAtq55WO53waxnw5kqYfggAUQwGYisO2EdLlXdMKgEcETpSVAyatDVycLKxM OkGM8A+i/zuI6ux7HDsUWCDBkVwyoMzvQhiQOhc0b70DpvtV028YwO3ezRc96d3jR13d K/irYGRbk68bCobEPiGPaPlvQx9Y1Pro7xOGf0oF1uKB/Spo6UWufFjnfVgpt0dtfOSx UzHeGmKdzsx34SHaZmIm6oHVPHyLTVZDs5MHA8AaDmirfCD2ZCD4PDEqy7CTvF5nFYdQ 8DEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bGsePVhSWSTT/gjGm4Hf99qS9oJJC620C+9nA/2eb/M=; b=BfnIp8gdX71zGA9uci1jZuOslwNI2dGk7/ENG6EtfLMmBn591V2tOOH5dtT2Eyjkzm xi2I1ou/zqJBZ6nPCUPHS2zugZ8hN5wvWbTJtd92HXJe+fRu16EEelCgcp8R9JBuK3g8 tpaten6IDZlD5hF4lVKF1YJiv6HeOy2AvwdSESk0wlDng4UedTvMYzq2i1G9vfFZ4CTE NpKHN60UYI4iSmImYlzP9i8t7UWe9G77UP8D4VqLQa+PkPi8kvphZf4LMY6zTxCTK0y7 u3zSwrI8PBe021Beou5aY/jBXW/2mdaFJHurvTCV4kQCIYdqaXzowjEpw63gIAY+UQ9T VjFA== X-Gm-Message-State: AKaTC01mnTsAb23LTOGNsYTV21th2gP06PL+hAGysK44A2FKDdnpaXnTCddkXW6AkuWJfnqSR/4l7vyk+FmAow== X-Received: by 10.129.40.149 with SMTP id o143mr38039269ywo.106.1480572807846; Wed, 30 Nov 2016 22:13:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.170.79 with HTTP; Wed, 30 Nov 2016 22:13:27 -0800 (PST) In-Reply-To: References: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 1 Dec 2016 00:13:27 -0600 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1140865a46c448054292b8e3 Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 06:13:31 -0000 --001a1140865a46c448054292b8e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Carsten, On Wed, Nov 30, 2016 at 10:54 PM, Carsten Bormann wrote: > Hi Spencer, > > On 1 Dec 2016, at 04:48, Spencer Dawkins > wrote: > > > > or other CBOR extension proposals > > So far, the text has been careful to limit the scope to work that uses > existing extension points defined by RFC 7049 (for the two documents cite= d. > specifically, by defining CBOR tags). "or other CBOR extension proposals= =E2=80=9D > might be taken to completely open Pandora=E2=80=99s box here. > > But I agree that if something comes up that is of the same quality as the > two documents, the WG should be allowed to look into it. > Thanks for the quick response. So, would something like "Where these CBOR extensions, or other CBOR extension proposals of similar quality, are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well." be worth saying? And either answer is OK, I'm just trying to think ahead :-) Spencer --001a1140865a46c448054292b8e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Carsten,

On Wed, Nov 30, 2016 at 10:54 PM, Carsten Bormann <cabo@tzi.org= > wrote:
Hi = Spencer,

On 1 Dec 2016, at 04:48, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>
> or other CBOR extension proposals

So far, the text has been careful to limit the scope to work that us= es existing extension points defined by RFC 7049 (for the two documents cit= ed. specifically, by defining CBOR tags).=C2=A0 "or other CBOR extensi= on proposals=E2=80=9D might be taken to completely open Pandora=E2=80=99s b= ox here.

But I agree that if something comes up that is of the same quality as the t= wo documents, the WG should be allowed to look into it.

Thanks for the quick response.=C2=A0

<= div>So, would something like=C2=A0

"Where these CBOR extensions, or other CBOR extension pro= posals of similar quality,=C2=A0
are=C2=A0deemed useful and do not require significant new development, the CBOR = WG
wi= ll=C2=A0complete these specificatio= ns as well."=C2=A0

be worth saying?=C2=A0

And either answer is OK, I'm = just trying to think ahead :-)

Spencer --001a1140865a46c448054292b8e3-- From nobody Wed Nov 30 23:37:55 2016 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 2C83C1295C5; Wed, 30 Nov 2016 23:37:47 -0800 (PST) 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 kDGpk_nmZtwE; Wed, 30 Nov 2016 23:37:45 -0800 (PST) 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 56511126BF7; Wed, 30 Nov 2016 23:37:45 -0800 (PST) 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 uB17bfgs012512; Thu, 1 Dec 2016 08:37:41 +0100 (CET) Received: from [172.20.10.2] (ip-109-47-2-226.web.vodafone.de [109.47.2.226]) (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 3tTpz775k6z8LPW; Thu, 1 Dec 2016 08:37:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: Date: Thu, 1 Dec 2016 08:36:51 +0100 X-Mao-Original-Outgoing-Id: 502270611.243685-0d807008d26903f803780922c7bd98a7 Content-Transfer-Encoding: quoted-printable Message-Id: <8172F9AA-285A-4279-9982-E965DF8DA404@tzi.org> References: <148056410616.9582.5302012347523434613.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3251) Archived-At: Cc: cbor@ietf.org, The IESG , cbor-chairs@ietf.org Subject: Re: [Cbor] Spencer Dawkins' No Objection on charter-ietf-cbor-00-01: (with COMMENT) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 07:37:47 -0000 On 1 Dec 2016, at 07:13, Spencer Dawkins at IETF = wrote: >=20 > "Where these CBOR extensions, or other CBOR extension proposals of = similar quality,=20 > are deemed useful and do not require significant new development, the = CBOR WG > will complete these specifications as well.=E2=80=9D=20 Works for me, but I=E2=80=99m sure there will be people who want to = wordsmith further on the somewhat fuzzy =E2=80=9Cof similar quality=E2=80=9D= . (It works for me because I trust the chairs and ADs to interpret this = in a useful way.) Gr=C3=BC=C3=9Fe, Carsten