Concise Binary Object Representation (CBOR) Sequences
RFC 8742
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
Alvaro Retana No Objection
Roman Danyliw No Objection
Warren Kumari No Objection
Thank you for writing this.
Éric Vyncke No Objection
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).
(Adam Roach; former steering group member) (was No Objection) Yes
(Alexey Melnikov; former steering group member) Yes
IANA is still waiting for DE review.
(Barry Leiba; former steering group member) Yes
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?
(Benjamin Kaduk; former steering group member) Yes
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?
(Alissa Cooper; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection