[Cbor] Éric Vyncke's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-cbor-7049bis-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. While it is rather long, it is
exhaustive and usually quite clear (with exceptions see below).

Thanks to Eve Schooler for her very detailed IoT directorate review at
https://datatracker.ietf.org/doc/review-ietf-cbor-7049bis-14-iotdir-telechat-schooler-2020-09-08/
I strongly suggest to the authors to follow Eve's recommendation to clarify and
make the text easier to read.

Please find below a couple of non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3.4  --
Is there a reason why "specifically, tag number 25 and tag number 29" have no
reference to a RFC ? The reader would benefit from some short description. This
oddity was also mentioned by Eve in her review, so, I strongly suggest to
address the issue.

-- Section 3.4.5.2 --
As noted by other AD, I am puzzled by the added value of checking whether a
string is PCRE or ECMA262.

-- Section 3.4.6 --
I like this idea of 'magic number' but, as I am not a Unicode expert, I wonder
whether "In particular, 0xd9d9f7 is not a valid start of a Unicode text in any
Unicode encoding if it is followed by a valid CBOR data item." will always
stand true.

-- Section 4.2.1 --
Humm this section says "MUST be as short as possible" while the introduction
says "optimize for CPU not for bytes". Same applies for sorted keys... How can
we reconciliate ? Suggestion: add some text about this apparent goals conflict.