[Cbor] Éric Vyncke's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-cbor-file-magic-11: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

Thank you for the work put into this document. This document describes a nice
addition to CBOR.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Christian Amsüss for the shepherd's write-up even if the
justification for the intended status is somehow weak (but at least present).

I hope that this helps to improve the document,

Regards,

-éric

## General comment

I was about to ballot a DISCUSS due to the absence of BCP14 and any normative
language in a standard track document. Explanations from the authors/WG/AD will
be more than welcome as I am not convinced by the shepherd's explanation
("let's avoid down ref in the future").

## Abstract

Just wondering whether the "on-disk" actually reflects the use of the Unix
`file` command as this command also works on many other file systems / storage.

The abstract seems to indicate that there is ONE format while the rest of the
document is about THREE formats. Suggest to update the abstract to reflect the
choice among 3 formats.

## Section 1

Unsure whether the comparison of Unix file with TCP/IP stream brings any value.

Should there be a reference for "MIME type" ?

Should there be a reference for "media type registration template" ?

BTW, this section reads like a nice set of anecdotes, which is easy to read,
but a more logical flow would be a plus for the reader.

A reference to CBOR RFC 8742 is probably required.

"magic number" should perhaps be introduced before citing it ?

Unsure whether the paragraph "A major inspiration ..." brings any value to the
text.

## Section 1.2

Is the 'magic number' unique per CBOR protocol or just for any CBOR protocol?
(i.e., this definition seems really restricted to CBOR and not to `file`)
Should it also be distinct from other 'magic numbers' in /etc/magic ?

## Section 2

I am confused, and probably misread the document, but earlier I had the
impression that THREE methods will be specified in this document and this
section defines only TWO.

## Section 2.1

Should the 4-byte magic number be different than the existing 'magic numbers'
supported by `file` ?

## Section 2.2.1

I must be really confused (and sorry about that) but the example contains a
0x00 which contradicts the above "avoid values that have an embedded zero byte"
(from section 2.1).

## Section 3

I really love the "COVID vaccination certificate that needs to be displayed in
QR code form" example (just use "COVID-19" perhaps) but should a reference be
added ?

The considerations for the protocol designers do not really fit my ideas about
a standard track document but rather of a BCP.

# NITS

## Section 1

In "two possible methods of enveloping data are presented: a CBOR Protocol
designer will specify one", should the ":" rather be a ";" ? Anyway, the RFC
editor will review it ;-)

## Section 2.3

Please be consistent with the use of lower case or upper case for hexadecimal
numbers, e.g., 0x42_4f_52