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

Carsten Bormann <cabo@tzi.org> Wed, 25 September 2019 12:53 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 DCF8212022C; Wed, 25 Sep 2019 05:53:57 -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 zfPUXCqMZ3yc; Wed, 25 Sep 2019 05:53:55 -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 4FC10120220; Wed, 25 Sep 2019 05:53:55 -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 46ddKY4M8Nz10By; Wed, 25 Sep 2019 14:53:53 +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: <156885006199.4487.4211790094945761661.idtracker@ietfa.amsl.com>
Date: Wed, 25 Sep 2019 14:53:53 +0200
Cc: The IESG <iesg@ietf.org>, cbor@ietf.org, Jim Schaad <ietf@augustcellars.com>, draft-ietf-cbor-sequence@ietf.org, cbor-chairs@ietf.org
X-Mao-Original-Outgoing-Id: 591108831.742222-57cbad3faf60b1ed7bf97d6460a84c58
Content-Transfer-Encoding: quoted-printable
Message-Id: <30CAE7A3-0D94-45CC-9385-FBBD2A30B22F@tzi.org>
References: <156885006199.4487.4211790094945761661.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/l729V03OPtTc0FR475fAQXnE8KU>
Subject: Re: [Cbor] Benjamin Kaduk'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:53:58 -0000

Hi Benjamin,

thank you for your review and your Yes vote.

> On Sep 19, 2019, at 01:41, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> 
> […]
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ———————————————————————————————————
> On Sep 19, 2019, at 01:40, IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:
> 
> Section 2
> 
>   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.)
> 
> nit: I think s/each of which/each of which is delivered/, or just take Barry's
> suggestion that addresses the nit differently.

I went for Barry’s suggestion (with a small addition).

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

> Section 3
> 
>   The use case for the "+cbor-seq" structured syntax suffix is the same
>   as for "+cbor": It SHOULD be used by a media type when parsing the
> 
> nit: if the use case is literally "the same as" for "+cbor" then there
> would seem to be literally no value in having "+cbor-seq".  So perhaps
> “essentially the same as" or similar would be more appropriate?

I went for “analogous”, because this really is an analogy.

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

> Section 5
> 
> I might note that when COSE is applied to the elements of a sequence,
> the cryptographic protection is on a per-element basis, and thus there
> is no guarantee of relationship between level of protection, source
> authentication, time of generation, etc., across members of the
> sequence.

(See previous message.)

> Section 6.1
> 
> It's probably best to treat the following as a side note and thus not an
> actionable comment, but couldn't the URL fragment fairly easily be used
> to extract numbered elements of the sequence?

This is indeed a possibility.  However, I think this subject should better be addressed again when we have a “JSON pointer”/“JSON path” like way to reach into CBOR data structures, which we could use as a fragment identifier syntax for CBOR data items as well.  We can then treat the CBOR sequence similar to a top level array in a CBOR data item (and this also allows us to reach into specific items of the sequence).

(The original reason we don’t have a fragment syntax is that we simply copied json-seq, which doesn’t have one either.)

Grüße, Carsten