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

[Amanda Baber via RT <[e-mail]>]

Hi all,

We've made the following change in the "Semantics" field for CBOR Tag values 1668546817-1668612095:

OLD:

the representation of content-format ct < 65025 is indicated by tag number TN(ct) = 0x63470101 + (ct / 255) * 256 + ct % 255

NEW:

the representation of content-format ct < 65025 is indicated by tag number TN(ct) = 0x63740101 + (ct / 255) * 256 + ct % 255

Please see
https://www.iana.org/assignments/cbor-tags

Best regards,

Amanda Baber
IANA Operations Manager

On Fri Aug 05 23:51:59 2022, [e-mail] wrote:
> 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
> >>>
> >>
> >