[Cbor] Review of draft-bormann-cbor-sequence

Jim Schaad <ietf@augustcellars.com> Wed, 15 May 2019 02:56 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 17324120232; Tue, 14 May 2019 19:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2sqO1DRbcIkJ; Tue, 14 May 2019 19:56:57 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B22C1201D0; Tue, 14 May 2019 19:56:54 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 14 May 2019 19:56:48 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-bormann-cbor-sequence@ietf.org>
CC: <cbor@ietf.org>
Date: Tue, 14 May 2019 19:56:45 -0700
Message-ID: <01f201d50ac9$d6b1abd0$84150370$@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: AdUKwjido9sWYy7KRCib8Io9670liQ==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/PlL34l46dowgmLpVZJVJxZnDnOA>
Subject: [Cbor] Review of draft-bormann-cbor-sequence
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, 15 May 2019 02:57:00 -0000

1.  Introduction:  I think that I need a little bit more description of what
you consider to be a streaming parse/encoder.   At a minimum one would
potentially need to the ability to run a parser and recover from an error
where not enough bytes exist to try again after more bytes show up.  To me
that is a variant of a streaming parser.

2.  Section 2 - Definition of  a CBOR Sequence:  This took me a couple of
times to realize that this was being defined in a recursive manner.  I think
that making this more explicit would be good.

3.  Section 2 - I think that I would remove the parenthesis in the third
paragraph.  This is almost the entire paragraph.

4. Section 2 - For second decoding bullet.  This is describing a single pass
decoding, it is probably worth describing a streaming decoding at this point
as well.

5.  Section 2 - A program, not the decoder, may also be able to recover by
decoding individual fields looking for a pattern that matches an expected
structure.  As an example, looking for a byte which corresponds to an array
of 3 items and then test decoding to see if it works and continue from that

6.  Section 2 - The phrase "truncation of the last"  to me reads as the same
as the last data item is missing.  A better term might be "truncation inside
of the last" as that implies it is inside of the last item and not the last
item in its entirety.   It may also be worth while to note that this is only
true with known fixed length inputs and not with streamed input.

7.  Section 3 - The first paragraph starting with "It SHOULD" does not scan.
Please re-write

8.  Section 2 - It may be worthwhile to explicitly state that there is no
end of record indicator as well.  This is implied but not explicitly said.