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

[Sandy Ginoza <[e-mail]>]

Hi IANA,

We are almost ready to publish this document.  Please note that we received the following note from Carsten on 19 July.  The document has been updated accordingly.  As Carsten notes, this requires an update to the IANA site.  Please see the updates in Section 4.3 at <file:///Volumes/rfcpa/inc-work/rfc9277-diff.html>. 

> A user of draft-ietf-cbor-file-magic just made us aware that there are two swapped digits in the draft we actually submitted:
> 
> The number 0x63740101, which occurs twice (and 8 times more without 0x), has been copied incorrectly into the formula:
> 
> 	• TN(ct) = 0x63470101 + (ct / 255) * 256 + ct % 255
> 
> Where it occurs as 0x63470101 (74 ➔ 47, also twice).  This number is incorrect and does not result in the computed numbers found throughout the draft.
> 
> Unfortunately, one of the two occurrences is in the IANA Considerations, so the registry currently also has the wrong formula and will need to be corrected.
> 
> We will have time to correct this in AUTH48, but I wanted to make sure the fact that there is this mistake is known as early as possible.
> 
> Grüße, Carsten


Please review and update the registry accordingly and/or let us know if there are any concerns or questions. 

Thanks!
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
>>> 
>> 
>