Hi Ken and Daniel, Thank you for your replies. We have updated as requested.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc10022.xml https://www.rfc-editor.org/authors/rfc10022.txt https://www.rfc-editor.org/authors/rfc10022.html https://www.rfc-editor.org/authors/rfc10022.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc10022-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc10022-auth48diff.html (Final Review changes) https://www.rfc-editor.org/authors/rfc10022-auth48rfcdiff.html (Final Review changes side by side) Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. We will await approvals from each party listed on the Final Review status page below prior to moving this document forward in the publication process. For the Final Review status of this document, please see: https://queue.rfc-editor.org/final-review/rfc10022/ Thank you, Alanna Paloma RFC Production Center > On Jul 22, 2026, at 6:20 AM, Daniel Eggert > <[email protected]> wrote: > > Replies inline. > > >> Den 22. jul. 2026 kl. 12.24 skrev [email protected]: >> >> Greetings, >> >> While reviewing this document during Final Review, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> 1) <!-- [rfced] Please review the "type" attribute of each sourcecode element >> in the XML file to ensure correctness. If the current list of preferred >> values for "type" >> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >> does not contain an applicable type, then feel free to let us know. >> Also, it is acceptable to leave the "type" attribute not set. >> --> > > This "sourcecode" doesn't match any of those types. It's monospaced > plain-text. I would just leave it without a "type". > > >> >> 2) <!-- [rfced] The file below lists terms enclosed in <tt> in this document. >> Some of these terms appear both with and without <tt>. Please review to >> ensure the usage of <tt> is correct and consistent. Let us know if any >> updates are needed. >> >> <tt>ESEARCH</tt> >> <tt>EXISTS</tt> >> <tt>EXPUNGE</tt> >> <tt>LIMIT</tt> >> <tt>NO</tt> >> <tt>TOOFEW</tt> >> <tt>TOOMANY</tt> >> <tt>UIDBATCHES</tt> >> <tt>VANISHED</tt> >> >> <tt>163886:99703</tt> >> <tt>163886:99697</tt> >> <tt>99702:99697</tt> >> <tt>99696:20358</tt> >> <tt>7829:302</tt> >> <tt>7829:1</tt> >> <tt>4:1</tt> >> <tt>1:4</tt> >> <tt>$</tt> >> --> > > Yes, these should all use <tt>. > > >> >> 3) <!-- [rfced] FYI - We have added an expansion for the following >> abbreviation >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> Unique Identifier (UID) >> --> > > Yes, that's correct. > > >> 4) <!-- [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. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> In addition, please consider whether "traditional" should be updated for >> clarity. >> While the NIST website >> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >> >> indicates that this term is potentially biased, it is also ambiguous. >> "Tradition" is a subjective term, as it is not the same for everyone. >> --> > > I like Ken's suggestion to use "conventional" instead of "traditional". > > > > /Daniel -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
