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..."