Re: [auth48] [AD] AUTH48: RFC-to-be 9277 <draft-ietf-cbor-file-magic-12> for your review

[Carsten Bormann <[e-mail]>]

Hi Sandy,

> On 5. Aug 2022, at 04:38, Sandy Ginoza <[e-mail]> wrote:
> 
> We have updated the document as described below, with a few minor updates (e.g., added commas or abbreviation expansion). 

Thank you.

Here are my comments from a full reread:

(1)
Abstract:
OLD:
   This document defines a stored ("file") format for Consice Binary
NEW:
   This document defines a stored ("file") format for Concise Binary

(2)
1. Introduction:
OLD:
certain ASN.1-based systems where most files are Privacy-
   Enhanced Mail (PEM) encoded; 
NEW:
certain ASN.1-based systems where most files are Privacy-Enhanced Mail (PEM) encoded; 

(No space after Privacy-.)

(3)
1. Introduction:
OLD:
   determine it by other means.  For instance, in classical macOS, a
NEW:
   determine it by other means.  For instance, in classical Mac OS, a

(Classical Mac OS was styled this way, as opposed to modern macOS, which was named Mac OS X or variants thereof in between.)

(4)
1. Introduction:
OLD:
   A common way to identify the type of a file from its contents is to
   place a "magic number" at the start of the file contents [MAGIC].  In
   the media type registration template [RFC6838], it is noted that a
   magic number is asked for, if available, as is a file extension.
NEW:
   A common way to identify the type of a file from its contents is to
   place a "magic number" at the start of the file contents [MAGIC].  In
   the media type registration template [RFC6838], a
   magic number is asked for, if available, as is a file extension.

(The note is not in 6838, but here — but it is not necessary to phrase this as a note in the introduction.  A “for instance” or some such might be added.)

(5)
1. Introduction:
OLD:
   A third method is also proposed by which this CBOR format tag is
NEW:
   A third method is also proposed by which a CBOR format tag is

(There is no referent for “this” here, and it is not needed either.)

(6)
2.3.1.  Example:
OLD
   as assigned for application/missing-blocks+cbor-seq of the "CAP
NEW:
   as assigned for application/missing-blocks+cbor-seq of the "CoAP

(7)
3. Security Considerations:
OLD:
   of a check versus a use issue.)  For example, end-point assessment
NEW:
   of a check versus use issue.)  For example, end-point assessment


(8)
> - Global s/1668547090/1668574090 (see mail from Carsten dated 19 July 2022)

I’m a bit confused here, as the mail dated 2022-07-19 was about the fix s/0x63470101/0x63740101/g in the TN formulae, which has been successfully executed.

The value 1668574090 is an incorrect replacement for 1668547090.
This change (5 places) needs to be reverted.
Similar for 1668574250, which needs to revert to 1668547250 (2 places).

(9)
4. IANA Considerations
It is slightly weird that the introduction of 4 introduces Sections 4.1 and 4.3, but not Section 4.2.  Maybe add in between:

NEW:
  Section 4.2 documents the allocation for a CBOR tag to be used in the CBOR-Labeled Non-CBOR Data Enveloping Method (Appendix D, which also shows examples).

(Cross reference the links for Section 4.2 and Appendix D, obviously.)

(10)
A.2.  Can many items be trivially concatenated?:
OLD:
   The program involved may throw errors or warnings on the Labeled CBOR
   Sequence if they have not yet been updated, but this may not be a
NEW:
   The programs involved may throw errors or warnings on the Labeled CBOR
   Sequence if they have not yet been updated, but this may not be a

(Or: A program… if it has not yet…)

(11)
Appendix B.  CBOR Tags for CoAP Content Formats:

OLD:
   together with a content encoding.
NEW:
   together with a content coding (see Section 8.4.1 of [RFC9110]).

(And add RFC 9110, which has since been published, to the informative references.)

(12)
OLD:
   Tags 55800 (Section 2.3) or 55801 (Appendix D):  the byte string
      "BOR", signifying that the representation of the given content-
NEW:
   Tags 55800 (Section 2.3) or 55801 (Appendix D):  the byte string
      'BOR', signifying that the representation of the given content-

(‘BOR’ is diagnostic notation for a byte string; “BOR” swaps this out confusingly for that of a text string, which is not what this is.)

A few more of these:

(13)
Appendix D.  Using CBOR Labels for Non-CBOR data
OLD:
   3.  The tag content is a 3-byte CBOR byte string containing
       0x42_4F_52 ("BOR" in diagnostic notation).
NEW:
   3.  The tag content is a 3-byte CBOR byte string containing
       0x42_4F_52 ('BOR' in diagnostic notation).

(14)
OLD:
   encoded data item for the 3-byte string 0x42_4f_52 ("BOR" in
   diagnostic notation).
NEW:
   encoded data item for the 3-byte string 0x42_4f_52 ('BOR' in
   diagnostic notation).


Grüße, Carsten