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

[Sandy Ginoza <[e-mail]>]

Hi Carsten,

Thanks for your thorough review.  The document has been updated as described below.  Please review and let us know if any additional updates are needed.

The files have been posted here:
   https://www.rfc-editor.org/authors/rfc9277.txt
   https://www.rfc-editor.org/authors/rfc9277.pdf
   https://www.rfc-editor.org/authors/rfc9277.html
   https://www.rfc-editor.org/authors/rfc9277.xml

These diffs highlight the only the recent updates:
   https://www.rfc-editor.org/authors/rfc9277-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9277-lastrfcdiff.html (side by side)

AUTH48 diff: 
   https://www.rfc-editor.org/authors/rfc9277-auth48diff.html

Comprehensive diffs: 
   https://www.rfc-editor.org/authors/rfc9277-diff.html
   https://www.rfc-editor.org/authors/rfc9277-rfcdiff.html (side by side)

Thanks,
Sandy 



> On Aug 5, 2022, at 5:47 AM, Carsten Bormann <[e-mail]> wrote:
> 
> 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
>