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

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) 
the following questions, which are also in the XML file.

1) <!-- [rfced] For clarity, we suggest the following update to the title.  
Please let us know if this is acceptable.  
	 
Original:
On storing CBOR encoded items on stable storage

Current:
On Storing CBOR-Encoded Items on Stable Storage

Perhaps:
Stable Storage for Items Encoded in Concise Binary Object Representation (CBOR)
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


3) <!-- [rfced] For clarity, may we update the text as shown below or does 
this change the intended meaning? 

Current:
   This document defines a stored ("file") format for CBOR data items
   that is friendly to common file type recognition systems such as the
   Unix file(1) command.

Perhaps: 
   This document defines a stored ("file") format for CBOR data items
   that is friendly to systems that recognize common file types such 
   as the Unix file(1) command.
-->


4) <!-- [rfced] How is the file(1) command confused?  Does it not
know the difference between the encoding and the content?
Does the encoding throw it off?  Maybe clarifying this
sentence would be helpful for the reader.

Original:
   A challenge for the file(1) command is often that it can be confused
   by the encoding vs. the content.
   
Perhaps:
   A frequent challenge for the file(1) command is that it can be confused
   because it cannot differentiate between the encoding and the content.
-->


5) <!-- [rfced] FYI: We updated "apk" to APK. Please let us know if there 
are any objections.

Original:
   For instance, an Android "apk" (as
   used to transfer and store an application) may be identified as a ZIP
   file.
-->


6) <!-- [rfced] This sentence is a bit tough to parse.  Please 
consider whether either of the suggested updates is more clear 
and is consistent with the intended meaning. 

Original:
   Additionally, both OpenOffice and MSOffice files are ZIP files
   of XML files, and may also be identified as a ZIP file.

Perhaps A:
   Additionally, both OpenOffice and MSOffice files are ZIP files
   of XML files, and may be identified as XML or ZIP files.

Perhaps B:
   Additionally, the application XML files of both OpenOffice 
   and Microsoft Office use the ZIP archive format, and they 
   may also be identified as ZIP files.
-->


7) <!-- [rfced] We had a few questions about this sentence.  If 
our suggested text does not correctly capture your intent, please 
let us know how we may rephrase.

a) The use of "derive...to" seems odd.  We generally see "derive...from".

b) May we clarify what is not in CBOR form?

Original:
   This includes a simple way to
   derive a magic number to content-formats as defined by [RFC7252],
   even if not in CBOR form.

Perhaps:
   This includes a simple way to derive a magic number [for/from?] 
   content-formats as defined in [RFC7252] even if the file is
   not in CBOR form.
-->


8) <!-- [rfced] For clarity, may we update the sentence as follows? 

Original:
   A major inspiration for this document is observing the disarray in
   certain ASN.1 based systems where most files are PEM encoded; these
   are then all identified by the extension "pem", confusing public
   keys, private keys, certificate requests, and S/MIME content.

Perhaps:
   A major inspiration for this document is to disambiguate the 
   disarray observed in certain ASN.1-based systems where most 
   files are PEM encoded; these files are identified by the 
   extension "pem", which confuses public keys, private keys, 
   certificate requests, and S/MIME content.
-->


9) <!-- [rfced] It seems like this text is referring to future 
registrations, rather than values being registered by this document.  
Should the regisration template refer to this document AND the document 
that defines the semantics for the requested registration? 

Original:
   In the template, it is suggested to include
   a reference to this specification (RFC XXXX) alongside the
   Description of semantics.
   // (Note to RFC Editor: Please replace all occurrences of "RFC XXXX"
   // with the RFC number of the present specification and remove this
   // note.)
-->


10) <!-- [rfced] Note that we changed the instance of "US-ASCII" to "ASCII". 
Please let us know if there are any objections. 

Original:
   The use of a sequence of four US-ASCII [RFC20] codes which are
   mnemonic to the protocol is encouraged, but not required (there may
   be reasons to encode other information into the tag; see Appendix B
   for an example).
-->


11) <!-- [rfced] "form a representation that is described by" is 
tough to parse.  Is the CoAP  Content-Format number input to the 
representation?  The relationship is unclear.  Please consider 
whether the text can be clarified.

Original:
   For CBOR data items that form a representation that is described by a
   Constrained Application Protocol (CoAP) Content-Format Number
   (Section 12.3 of [RFC7252] and Registry CoAP Content-Formats of
   [IANA.CORE-PARAMETERS]), a tag number has proactively been allocated
   in Section 4.3 (see Appendix B for details and examples).
-->


12) <!-- [rfced] Note that we have removed the relative attribute 
of xrefs used to include URLs to IANA registries per discussion with 
IANA.  I know we discussed this with you recently and allowed the use 
of the relative attribute in another document.  Per further discussion 
with IANA, they recommended against use of the registry-specific URLs.  
The web portion of the style guide was recently updated to make this 
more clear. -->


13) <!-- [rfced] Please review the use of "operating systems 
configurations".  Is this possessive, plural, or plural possessive?

Original:
   Similarly, depending on operating systems configurations and related
   properties of the execution environment the labeling might influence
   the default application used to process a file in a way that may not
   be predicted by a protective application.

Perhaps:
   Similarly, depending on the configurations of the operating system 
   and the related properties of the execution environment, the labeling 
   might influence the default application used to process a file in a 
   way that may not be predicted by a protective application.
-->


14) <!-- [rfced] Will the ".." notation be clear for the reader?  

Original Section 4.1: 
   However, the following
   16-bit big-endian value 0xf8.. is not a valid second sequence
   according to [RFC2781].

Original Section 4.2:
   However, the following
   16-bit big-endian value 0xf9.. is not a valid second sequence
   according to [RFC2781].

We typically see this used for a range of numbers.  For example, 
this is from RFC 8710:
 

                      | Serialization  | Value      |
                      +================+============+
                      | 0x00..0x17     | 0..23      |

                      | 0x18 0xnn      | 24..255    |

                      | 0x19 0xnn 0xnn | 256..65535 |
-->


15) <!-- [rfced] Per the message from Carsten below, we have updated 
instances of 63470101 to 63740101.  Please review carefully to ensure 
the updates have been made correctly, and let us know if any updates 
are needed.  We will ask IANA  to update the registry once the updates 
are confirmed.

>From Carsten: 
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.
-->


16) <!--[rfced] May we update the citations/reference pointing to 
STD 94 to instead point to RFC 8949?  As there are a number of 
instances referencing specific sections from RFC 8949, this seems 
like best practice for in case more RFCs are added to STD 94. -->


17) <!-- [rfced] For readability, should "on wire" and "on-wire" be 
"on the wire"? 

Originals:
   ... and then return the
   actual CBOR item, which could be anything at all, and could include
   CBOR tags that _do_ need to be sent on wire.

   A.1.  Is the on-wire format new?

   If the on-wire format is new, then it could be specified with the
   CBOR Tag Wrapped format if the extra eight bytes are not a problem.
   The stored format is then identical to the on-wire format.
-->


18) <!-- [rfced] Does "compiled/serialized" mean "compiled and serialized"?
If yes, may we update this text as follows:

Original:
   Instead, the IPC that is normally sent across
   the wire is compiled/serialized and placed in a file.

Perhaps:
   Instead, the IPC that is normally sent across
   the wire is compiled, serialized, and placed in a file.
-->


19) <!-- [rfced] We are having trouble parsing this sentence.  
Does "for any language that encode to CBOR" mean "for any language 
that can be encoded as CBOR"?  


Original: 
   Additionally, this change
   allows the IPC to be described by CDDL, and for any language that
   encode to CBOR can be used.
-->


20) <!-- [rfced] Terminology

Should "tag" be capitalized when it follows CBOR?  Is "tag" lowercased 
when not referring to a specific CBOR tag?  We see the following: 

CBOR Tag
CBOR tags 
CBOR tag numbers 

In addition, should "Sequence tag" and "Tag Sequence" be consistent? 
CBOR Sequence tag
CBOR Tag Sequence

-->


21) <!-- [rfced] When we converted this document to v3, xml2rfc converted 
<spanx style="verb"> to <tt> and <spanx style="emph"> to <em>.

In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed. 

In the html and pdf outputs, the text enclosed in <em> is output in
italics. In the txt output, the text enclosed in <em> appears with an
underscore before and after.

Please review carefully and let us know if the output is acceptable or if 
any updates are needed.
-->


22) <!-- [rfced] Please review the "Inclusive Language" portion of 
the online Style Guide 
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script 
did not flag any terms or phrases.-->


Thank you.

RFC Editor


On Aug 3, 2022, at 2:03 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2022/08/03

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9277.xml
   https://www.rfc-editor.org/authors/rfc9277.html
   https://www.rfc-editor.org/authors/rfc9277.pdf
   https://www.rfc-editor.org/authors/rfc9277.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9277-diff.html
   https://www.rfc-editor.org/authors/rfc9277-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9277-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9277.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9277.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9277

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9277 (draft-ietf-cbor-file-magic-12)

Title            : On storing CBOR encoded items on stable storage
Author(s)        : M. Richardson, C. Bormann
WG Chair(s)      : Christian Amsüss, Barry Leiba

Area Director(s) : Murray Kucherawy, Francesca Palombini