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

[Carsten Bormann <[e-mail]>]

Hi Benjamin,

thank you for your review and your Yes vote.

> On Sep 19, 2019, at 01:41, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> […]
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ———————————————————————————————————
> On Sep 19, 2019, at 01:40, IETF Secretariat <[e-mail]> 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