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

[Carsten Bormann <[e-mail]>]

Hi Sandy,

thank you for the very quick turnaround before I vanish into a vacation!
I believe RFC 9277-to-be is now ready for publishing.

Grüße, Carsten

> On 2022-08-05, at 18:11, Sandy Ginoza <[e-mail]> wrote:
> 
> 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
>> 
>