Re: [Cbor] Barry Leiba's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)

Carsten Bormann <cabo@tzi.org> Wed, 25 September 2019 12:40 UTC

Return-Path: <cabo@tzi.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 495C3120143; Wed, 25 Sep 2019 05:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 a9OwgslXELBM; Wed, 25 Sep 2019 05:40:41 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176B0120073; Wed, 25 Sep 2019 05:40:41 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46dd2H3k2Nz10jC; Wed, 25 Sep 2019 14:40:39 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <156823422600.13495.6043888160887106070.idtracker@ietfa.amsl.com>
Date: Wed, 25 Sep 2019 14:40:39 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-cbor-sequence@ietf.org, Jim Schaad <ietf@augustcellars.com>, cbor-chairs@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 591108035.352281-1348de0d610eab33a17295bbee7726ae
Content-Transfer-Encoding: quoted-printable
Message-Id: <38F1C119-C40A-4E17-B49B-B681E7562525@tzi.org>
References: <156823422600.13495.6043888160887106070.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/wg0Jo_4mGO2Ao8bRWv300TbTc-8>
Subject: Re: [Cbor] Barry Leiba's Yes on draft-ietf-cbor-sequence-01: (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, 25 Sep 2019 12:40:44 -0000

Hi Barry,

On Sep 11, 2019, at 22:37, Barry Leiba via Datatracker <noreply@ietf.org> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-cbor-sequence-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.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-sequence/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for a fine and mostly easy-to-read document.  There’s just one bit that
> I find hard to read:
> 
> — Section 2 —
> 
>   Decoding a CBOR Sequence works as follows:
> 
>   o  If the CBOR Sequence is an empty sequence of bytes, the result is
>      an empty sequence of CBOR data model values.
> 
>   o  Otherwise, decode a single CBOR data item from the bytes of the
>      CBOR sequence, and insert the resulting CBOR data model value at
>      the start of the result of decoding the rest of the bytes as a
>      CBOR sequence.  (A streaming decoder would therefore simply
>      deliver zero or more CBOR data model values, each of which as soon
>      as the bytes making it up are available.)
> 
> I find the phrasing of the second bullet (the part “at the start of the result
> of decoding the rest of the bytes as a CBOR sequence.”) really hard to parse. 
> After a brief email exchange between Carsten and me before he zipped off on
> holidays, I propose this minor re-wording:
> 
> NEW
>   o  Otherwise, decode a single CBOR data item from the bytes of the
>      CBOR sequence, and insert the resulting CBOR data model value at
>      the start of the result of repeating this decoding process
>      recursively.  (A streaming decoder would therefore simply
>      deliver zero or more CBOR data model values, each as soon
>      as the bytes making it up are available.)
> END
> 
> Does that work for you, Carsten?

Almost.  
This doesn’t say what the decoding process is applied to, so I added “with the remaining bytes”:

* Otherwise, decode a single CBOR data item from the bytes of the CBOR
  sequence, and insert the resulting CBOR data model value at the
  start of the result of repeating this decoding process recursively
  with the remaining bytes.  (A streaming decoder would therefore
  simply deliver zero or more CBOR data model values, each as soon as
  the bytes making it up are available.)

Now in https://github.com/cbor-wg/seq/commit/ffa99b279f6ba91176b1af418388873f57390585

Grüße, Carsten