Ballot for draft-ietf-cbor-sequence
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
Thank you for writing this.
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).
IANA is still waiting for DE review.
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?
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?