[Cbor] WGLC review of draft-ietf-cbor-7049bis-09

Jim Schaad <ietf@augustcellars.com> Sat, 07 December 2019 00:49 UTC

Return-Path: <ietf@augustcellars.com>
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 434B3120044; Fri, 6 Dec 2019 16:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 jgRvBn7toTs3; Fri, 6 Dec 2019 16:49:10 -0800 (PST)
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 8F22B12006D; Fri, 6 Dec 2019 16:49:09 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Dec 2019 16:49:03 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-cbor-7049bis@ietf.org
CC: cbor@ietf.org
Date: Fri, 06 Dec 2019 16:49:02 -0800
Message-ID: <036501d5ac98$201dd490$60597db0$@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: AdWrzuIQWugvBxHJT5iTlKC/vhBbgg==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/eIqTh_-BaZbsc77pqkZUNEZ3kEw>
Subject: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09
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: Sat, 07 Dec 2019 00:49:11 -0000

Here is my WGLC review of the document.

*  In paragraph 2 of section 1, I don't understand how the first sentence
leads into the second sentence.  The first talks about specific design
goals, so I expected a discussion of some of those goals.  Instead I get a
discussion of the data model.  Paragraph 3 seems to follow better from the
first sentence of paragraph 2.

* In section 1 - paragraph 3.  I think this would fit better in section 1.1
rather than doing the forward reference.

* Section 1.2 - The terminology of Encoder and Decoder do not seem to match
each other.  The decoder decodes a well-formed CBOR data item.  The Encoder
generates the representation of a CBOR data item.  I assume that the decoder
should decode the representation of a well-formed CBOR data item.  The other
way around would be that the Encoder creates a well-formed CBOR data item.

* Section 2.2 last paragraph.  /be considered duplicates/be considered
duplicates, even if encoded as different major types,/   This is a belts and
suspenders suggestion but not something I would die for.

* Section 3 - para 1 - I do not believe that the encoding is summarized in
table 6.  This table just summarized the first byte of the encoding.  Is
this pointing to the right table or is the text just slightly messed up?

* Section 3.2.3 - The text is silent on a chuck being of length zero.
Should this be stated as discouraged but legal?

* Section 3.4.2 - Is this section and 3.4.3 supposed to be at the same level
s 3.4.1 or are they meant to be children?

* Section 4.1 - I don't know what 1_000_000_000 is supposed to represent.
My first assumption is that this is decimal, but it is not completely clear
that is correct.  

* Section 4.2.2 - Do we want to include a point in this section about saying
that applications may also need to set rules about how the content of a tag
is going to be expressed.  One example would be tag 6.1 where an application
could state that all times are in UTC or that times are only expressed to
the whole second.

* Section 5.2 - I think that /containing a byte string or a text
string/containing a byte string or containing a text string/  The byte
string is an error in itself, the text string is only an issue if the
embedded text is incorrect.

* Section 9.2 - Are you intending to update the template to point to this
document rather than saying with RFC 7049?  This is not stated here.

* Appendix B - Is there a reason why the first entry is Integer rather than
Unsigned Integer?

* Pseudo code - Should there be a break after case 7  (switch (mt))?  Having
it would be cleaner

* Appendix F -  This is missing some things which seem to be rather
important.
- New method to sort maps
- Lots of work on describing the CBOR Data Models
- Serialization considerations  + Preferred - Canonical
- Change in how validation/validity is described
- Appendix G

* Appendix G - /exexactly/exactly/


Jim