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

[Carsten Bormann <[e-mail]>]

Hi Lars,

thank you for these comments.

I have collected my proposed changes based on these comments in 

https://github.com/cbor-wg/cbor-magic-number/pull/21

> […]
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> "Abstract", paragraph 1, comment:
>>   This document defines an on-disk format for CBOR data items that is
>>   friendly to common on-disk recognition systems such as the Unix
>>   file(1) command.
> 
> I suggest to not talk about disks or stable storage in this abstract or the
> document body. What's actually being defined here is a file layout, and files
> can be stored on a variety of media. (And "file" isn't an "on-disk recognition
> system" either, it's a heuristic file type classifier.)

Indeed.
I have replaced “on-disk” by “stored”, and defined “file” for the purposes of this document.

(LE 1): Avoid "disk" (-> stored), define “file"
https://github.com/cbor-wg/cbor-magic-number/pull/21/commits/8152734


The rest of the comments below is addressed in
(LE 2): detailed comments

https://github.com/cbor-wg/cbor-magic-number/pull/21/commits/4d17d91


There will be a separate response to the GEN-ART review.

Grüße, Carsten


> 
> Section 2.1, paragraph 1, comment:
>>   The IANA policy for 4-byte CBOR Tags is First Come First Served, so
>>   all that is required is an email to IANA, having filled in the small
>>   template provided in Section 9.2 of [STD94].
> 
> FCFS codepoints may be requested in different ways in the future (e.g., web
> forms) in addition to email. The document need not go into details on how FCFS
> requests are made.
> 
> Section 2.1, paragraph 0, comment:
>>   In order to be in the four-byte range, and so that there are no
>>   leading zeros, the value needs to be in the range 0x01000000 (decimal
>>   16777216) to 0xFFFFFFFF (decimal 4294967295).
> 
> Including or excluding those two boundary values?
> 
> Section 2.1, paragraph -1, comment:
>>   The use of a sequence of four US-ASCII codes which are mnemonic to
>>   the protocol is encouraged, but not required.
> 
> If it's encouraged, why not require it, so that software can actually depend on
> it rather than needing to test for it? (Ditto for the suggestion to avoid
> zeroes.)
> 
> Thanks to Pete Resnick for their General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/UX8_f-rnj6FGgrSKRd-WCB8SuYg).
> 
> -------------------------------------------------------------------------------
> 
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
> 
> Paragraph 7768, nit:
>> shutting the daemon down. During testing it is sometimes the case that upgr
>>                                  ^^^^^^^
> A comma is probably missing here.
> 
> Paragraph 7824, nit:
>> ot normally loaded in the daemon. Instead the IPC that is normally sent acro
>>                                  ^^^^^^^
> A comma may be missing after the conjunctive/linking adverb "Instead".
> 
> 
>