Subject: [Cbor] Erik Kline's Yes on draft-ietf-cbor-7049bis-14: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 08 Sep 2020 16:58:00 -0700

Erik Kline has entered the following ballot position for
draft-ietf-cbor-7049bis-14: Yes

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:
----------------------------------------------------------------------

[[ questions ]]

[ section 3.3 ]

* Is it worth comparing and contrasting this encoding format with RFC 4506
  section 4.6?  Are they identical?

[[ comments ]]

[ section 1 ]

* I suppose XDR (4506) isn't well-known anymore.  :-(
  (no edits necessary, just a comment)

[[ nits ]]

[ section 1.2 ]

* "does not include following extraneous data"
  Is "following" important, or is it just "does not include other
  extraneous data"?

[ section 3.4.1 ]

* Perhaps "another type or that" -> "another type or a text string that"

[ section 5.6 ]

* Perhaps "Not accept maps duplicate keys"
  -> "Not accept maps with duplicate keys"?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Sep 2020 19:29:46 +0000

Thanks for your comments. Our notes are below.

--Paul Hoffman

They are not, and so probably not worth comparing, because...

>  (no edits necessary, just a comment)

...of that. That is, no one asked us to make the comparison when we wrote RFC 7049.

>  Is "following" important, or is it just "does not include other

Using "following" is important in that extraneous data could possibly appear before an item (although that seems weird).

> * Perhaps "another type or that" -> "another type or a text string that"

Good catch; fixed.

>  -> "Not accept maps with duplicate keys"?

Yes, definitely. Fixed.