Re: [Cbor] [Ext] Erik Kline's Yes on draft-ietf-cbor-7049bis-14: (with COMMENT)
Paul Hoffman <paul.hoffman@icann.org> Wed, 23 September 2020 19:29 UTC
Return-Path: <paul.hoffman@icann.org>
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 A02AE3A13D8; Wed, 23 Sep 2020 12:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyuXWPLGuYy0; Wed, 23 Sep 2020 12:29:50 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097203A13D6; Wed, 23 Sep 2020 12:29:50 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08NJTlMp014212 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2020 19:29:48 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Wed, 23 Sep 2020 12:29:46 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0659.006; Wed, 23 Sep 2020 12:29:46 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Erik Kline <ek.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "cbor@ietf.org" <cbor@ietf.org>
Thread-Topic: [Ext] Erik Kline's Yes on draft-ietf-cbor-7049bis-14: (with COMMENT)
Thread-Index: AQHWhjvkhWzVIQfBsU2ZD5Wsc+Iv+ql3KKoA
Date: Wed, 23 Sep 2020 19:29:46 +0000
Message-ID: <61ADE2F4-40F4-4EB9-AF18-1B8C9D68F0D7@icann.org>
References: <159960948017.26685.11511666915285639688@ietfa.amsl.com>
In-Reply-To: <159960948017.26685.11511666915285639688@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_7BCE656D-BE54-4505-AFB3-0F95EE92C12C"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-23_16:2020-09-23, 2020-09-23 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/ZbwM7GvEEyb9ru3IMpryTV8YXaY>
Subject: Re: [Cbor] [Ext] Erik Kline's Yes on draft-ietf-cbor-7049bis-14: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 19:29:52 -0000
Thanks for your comments. Our notes are below. --Paul Hoffman > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ questions ]] > > [ section 3.3 ] > > * Is it worth comparing and contrasting this encoding format with RFC 4506 > section 4.6? Are they identical? They are not, and so probably not worth comparing, because... > [[ comments ]] > > [ section 1 ] > > * I suppose XDR (4506) isn't well-known anymore. :-( > (no edits necessary, just a comment) ...of that. That is, no one asked us to make the comparison when we wrote RFC 7049. > [[ nits ]] > > [ section 1.2 ] > > * "does not include following extraneous data" > Is "following" important, or is it just "does not include other > extraneous data"? Using "following" is important in that extraneous data could possibly appear before an item (although that seems weird). > [ section 3.4.1 ] > > * Perhaps "another type or that" -> "another type or a text string that" Good catch; fixed. > [ section 5.6 ] > > * Perhaps "Not accept maps duplicate keys" > -> "Not accept maps with duplicate keys"? Yes, definitely. Fixed.
- [Cbor] Erik Kline's Yes on draft-ietf-cbor-7049bi… Erik Kline via Datatracker
- Re: [Cbor] [Ext] Erik Kline's Yes on draft-ietf-c… Paul Hoffman