Early Review of draft-ietf-cbor-file-magic-02
review-ietf-cbor-file-magic-02-artart-early-aboba-2021-08-03-00

Review of draft-ietf-cbor-file-magic-02
Reviewer: Bernard Aboba
Result: Ready with Issues

An overall comment. This document seems to propose more than one option in
several cases.  I wonder whether the multiple options will turn out to be
used in practice.  This makes me wonder if a document status of Experimental
might be a better choice (so we could try it out and see what turns out to be
needed), rather than BCP.

Section 2.

   A magic number is ideally a unique fingerprint, present in the first
   4 or 8 bytes of the file, which does not change when the contents
   change, and does not depend upon the length of the file.

[BA] Why have two supported lengths? I realize that they can be distinguished,
but having two potential lengths is likely to lead to one of them being less
widely supported or tested.

Section 3.2

[BA] Why support both CBOR Tag Wrapped and CBOR Tag Sequence?
The logic is explained in Section 4, but I'm not sure I buy it:

   "The use of CBOR Tag Wrapped format is easier to retrofit to an
   existing format with existing and unchangeable on-disk format."

[BA] Overall, it seems more likely to me that CBOR will be used for new file
formats than being retrofitted to new ones (which would be complicated by
backward compatibility issues). Or are there specific cases where a retrofit
is being seriously considered?

NITs:

Section 3.3:

"
   3.  The three byte CBOR byte string containing 0x42_4F_52.  When
       encoded it shows up as "CBOR"

...

   The third part is a constant value 0x43_42_4f_52, "CBOR".  That is,
   the CBOR encoded data item for the three byte sequence 0x42_4f_52
   ("BOR").  This is the data item that is tagged.
"

[BA] The latter text is more clear than the former, since 0x42_4F_52
is indeed "BOR". I'd suggest deleting the second sentence in 3, "When
encoded..."