Concise Binary Object Representation (CBOR) Sequences
RFC 8742

Note: This ballot was opened for revision 01 and is now closed.

Benjamin Kaduk Yes

Comment (2019-09-18 for -01)
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.

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?

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.

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?

Barry Leiba Yes

Comment (2019-09-11 for -01)
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?

(Alexey Melnikov) Yes

Comment (2019-09-19 for -01)
No email
send info
IANA is still waiting for DE review.

(Adam Roach) (was No Objection) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-09-18 for -01)
No email
send info
Thank you for writing this.

(Mirja Kühlewind) No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-09-12 for -01)
Carsten,

Thank you for the work put into this document. I have one minor COMMENT/suggestion and I am relying on the ART area directors for the integration in the CBOR framework. 

Regards,

-éric

== COMMENTS ==

-- Section 2 --
C.1) Unsure whether the "(Note that, ... valid JSON documents.)" is useful in this document (I told you it is a minor comment).

Magnus Westerlund No Objection