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

[Sandy Ginoza <[e-mail]>]

Hi Carsten and Michael, ADs*

We have updated the document as described below, with a few minor updates (e.g., added commas or abbreviation expansion).  

The current files are available 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

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)
   https://www.rfc-editor.org/authors/rfc9277-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9277-xmldiff2.html (side by side)


* ADs, please review the following updates in a comprehensive diff:
- Section 1, paragraphs 7 and 12
- Section 2.1, last paragraph 
- Global s/1668547090/1668574090 (see mail from Carsten dated 19 July 2022)
   

Authors - please see comments below.  Note that I have removed items that have been resolved and where no further discussion was needed.  

Thank you for your review.
RFC Editor/sg



>> 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.
>> -->
>> 
> 
> Well, we are not solving that problem, we are just observing the analog in a related domain.
> 
> Maybe:
> A major inspiration for this document is observing the disarray in
> certain ASN.1 based systems where most files are PEM encoded; 
> these files are all identified by the 
> extension "pem", which confuses public keys, private keys, 
> certificate requests, and S/MIME content.
> 
> Maybe confound or commingle?

The text has been updated as follows.  Please let us know if any updates are desired.

   A major inspiration for this document is observing the disarray in
   certain ASN.1-based systems where most files are Privacy- Enhanced
   Mail (PEM) encoded; these files are all identified by the extension
   "pem", which confounds public keys, private keys, certificate
   requests, and S/MIME content.



>> 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. -->
> 
> It appears there is nothing we can do about this.
> We have communicated the value of the direct URLs provided by the relative references.
> Clarifying this with IANA for future documents might be a good work item for RSWG.

We discussed this with IANA last week during IETF — my understanding is that IANA is working on having stable URLs for each registry, but they are not there yet.  Once the URLS are considered stable, we will gladly update the Style Guide to allow for registry-specific URLs.  


>> 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. -->
> 
> That seems to be about a limitation of the current RFCXML format.
> We do prefer citing STDs if we can.
> We note that the current text under [STD94] unambiguously specifies one RFC, 
> and the section references therefore work in draft-ietf-cbor-file-magic-12.html — what caused these to be lost?

The links were lost because use of <referencegroup> is recommended, even when there is      
only one RFC associated with a given STD/BCP number.  Currently, an xref cannot link directly to sections when   
<referencegroup> is used.  See <https://github.com/ietf-tools/xml2rfc/issues/639>. 

While it is not recommended, we have updated the reference and links as desired.



> 
>> 
>> 21) <!-- [rfced] When we converted this document to v3, xml2rfc converted 
>> <spanx style="verb"> to <tt> and <spanx style="emph"> to <em>.
> 
> (We don’t think you actually did this conversion.)

You’re right - apologies for the mistake and any confusion.  
Regarding the items below, please let us know if there are any updates needed.  

> We believe we used <em> and <tt> correctly in draft-ietf-cbor-file-magic-12.xml
> 
>> 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.
>> -->
> 
> Thank you for this reminder; we will look at this again in our full reread.
> 
>> 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.-->
> 
> We are not currently aware of instances of language that could be improved, but will look again in the full reread.
> 
>> --------------------------------------
>> 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
>> 
>> 
>