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

[John Scudder via Datatracker <[e-mail]>]

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

Thanks for this document. It seems useful, and the core specification
part in Section 2 is clear and understandable.

That said, it could be even friendlier to someone approaching it as a
CBOR n00b. I don't think that's a major concern, because I can’t
imagine why someone other than a hapless IESG member would approach this
document cold, without some reasonable background in CBOR. Still, if you
want an example of what I'm talking about, the casual "so that there are
no leading zeroes" in Section 2.1, with no whys or wherefores, felt a
bit like a scavenger hunt.

I also agree with a number of Lars's comments (in particular, what's a...
disk? Some technology from the 1900s?). Also Zahed's suggestion to move
Section 3 to an appendix.

Finally, while I am quibbling about style, I thought the trips down
memory lane and visits to sites of software grievances of Christmas
Past in Sections 1 and 3 slowed down the read without adding insight.

Finally, I do have one specific comment on where the text is unclear in
Section 2.2:

   A CBOR Protocol specification may specify the use of two tags only
   for specific cases.  For instance, it might use them when storing the
   representation in a local file or for Web access, but not when using
   them in protocol messages that already provide the necessary context.

The first sentence reads like a prohibition on specification of two tags
for general cases. (I don't know what that would mean, it's just a
straightforward way to parse it. "May" combined with "only" is
the difficult bit I think.) If your meaning is what I think it is,
substituting "might" for "may" would fix it.

But in the final analysis, the fact that all I've got is quibbles is
evidence of a job well done, thank you. :-)