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

[Sandy Ginoza <[e-mail]>]

Hi Carsten,

Great - I’ve marked your approval on the AUTH48 page <http://www.rfc-editor.org/auth48/rfc9277>.  We’ll wait to hear from Michael and Murray as well before continuing with publication. 

Enjoy your vacation!
Sandy 

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