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

Carsten Bormann <> Wed, 25 September 2019 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCF8212022C; Wed, 25 Sep 2019 05:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zfPUXCqMZ3yc; Wed, 25 Sep 2019 05:53:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FC10120220; Wed, 25 Sep 2019 05:53:55 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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 <>
In-Reply-To: <>
Date: Wed, 25 Sep 2019 14:53:53 +0200
Cc: The IESG <>,, Jim Schaad <>,,
X-Mao-Original-Outgoing-Id: 591108831.742222-57cbad3faf60b1ed7bf97d6460a84c58
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:
> […]
> ----------------------------------------------------------------------
> ———————————————————————————————————
> On Sep 19, 2019, at 01:40, IETF Secretariat <> 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

> 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

> 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