Hi Authors, Per discussion with Deb (AD), we have made some inclusive language updates (see updated files below).
Please note that we are awaiting for these follow-up questions/comments to be addressed: >>> ) We have a couple of questions regarding the index. >>> a. We note that there is a lot of index linking throughout the document. >>> For it to be most useful, it is ideal that the index points to where the >>> term is defined, and perhaps other key occurrences, not at each instance >>> where the term is mentioned. Therefore, may we clean up the index to only >>> link to definitions and key occurrences? For example, for “Header >>> Confidentiality Policy” and “HCP”, we suggest only including links to >>> Section 1.7 and Section 3, Paragraph 2, as these are where the terms are >>> defined and expanded on. >>> b. Within instances of “No Header Confidentiality Policy”, only “Header >>> Confidentiality Policy” is linked. Was the intention to include an index >>> entry for “No Header Confidentiality Policy” (if yes, we suggest including >>> only one link to Section 3.2.3 (“No Header Confidentiality Policy”)), or >>> may we remove the links from these occurrences? >> DKG? > > No opinion. ) As Alexey and Bernie do not have any preference, we will await word from Daniel regarding the questions about the index. Should Daniel have no preference, we will streamline the index accordingly. > - Is it correct, that in the IANA registration section this RFC-to-be has > no square brackets and a space betweeen "RFC" and its number, while > referred RFC do? (In IANA registry, both are external references?) Or > is this simply a typical case that is handled with by IANA in a standard > process? > > Example (in section 12.2): > > | Content-Type | | MIME | | [RFC4021] and RFC 9788 | ) Yes, it is correct and the style of the RFC Series to not have a linkable citation to this document in the running text (as this document is not listed as normative or informative in the References section). As self-references are potentially confusing, they are listed with a space between "RFC" and the number. Note that once this document is published, IANA will update its registry with the RFC number and link to the published RFC. > * Section 3.4.2 (minor) > > [ TBD: (@RFC-Editor): Are mitigatable and mitigatory exchangeable terms? To > me mitigatable (as originally )sounds more precise here, though unsure ] > > OLD > > An entry should not be marked as "Recommended" unless it has been > shown to offer confidentiality or privacy improvements over the > status quo and have minimal or mitigatory negative impact on messages > deliverability and security. > > NEW: > > An entry should not be marked as "Recommended" unless it has been > shown to offer confidentiality or privacy improvements over the > status quo and have minimal or mitigatable negative impact on messages > deliverability and security. ) Per Merriam-Webster, “mitigatory” is the adjective form of “mitigate”, and “mitigatable” is not a word. However, it seems that “mitigable” was intended, which is also an acceptable adjective form; the text now reflects “mitigable”. Also, it appears as if a section of the sentence was cut out in the OLD and NEW text. Please let us know if you would like that section cut out. Current: An entry should not be marked as "Recommended" unless it has been shown to offer confidentiality or privacy improvements over the status quo and have minimal or mitigable negative impact on messages to which it is applied, considering factors such as message deliverability and security. > 4.4.4 > > [ TBD (@RFC-Editor, @DKG, @Alexey): Not sure whether the comma preceding "or" > is correctly set. Shouldn't this be like ] > > OLD: > > Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may > populate the composer view using a combination of the referenced message's > From, To, Cc, Reply-To, or Mail-Followup-To Header Fields or any other > signals. > > > NEW: > Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may > populate the composer view using a combination of the referenced message's > From, To, Cc, Reply-To or Mail-Followup-To Header Fields, or any other > signals. ) As “Header Fields” applies to “From”, “To”, “Cc”, “Reply-To”, and “Mail-Followup-To”, we believe the commas in the OLD text are correct. However, we could update as follows: Perhaps: Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may populate the composer view using a combination of the referenced message's From Header Field, To Header Field, Cc Header Field, Reply-To Header Field, or Mail-Followup-To Header Field as well as any other signals. > * Appendix F.2. (minor) > > [ Note: The TXT version has the line break at an odd place. Suggest to remove > the introduced hyphen.] > > OLD: > > Although the PEF-2 scheme is only meant to be used between PEF- > 2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). > > NEW: > > Although the PEF-2 scheme is only meant to be used between PEF-2 > compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). ) With the hyphen removed, may we further update the text as follows? Perhaps: Although the PEF-2 scheme is only meant to be used between MUAs compatible with PEF-2, PEF-2 messages may end up at MUAs unaware of PEF-2 (in which case, they typically render badly). >> 15) <!--[rfced] May we update "genericize" to "generalize"? >> >> Original: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/genericize the local part of the >> From address, the domain will still leak. >> >> Perhaps: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/generalize the local part of the >> From address, the domain will still leak. >> --> > > No opinion. > @DKG? ) As “genericize” is not listed in the Merriam-Webster dictionary and has not been used in the RFC Series, we recommend updating it to “generalize”. Please let us know if we may do so. >> b) FYI - We removed the blank columns from Tables 2 and 3. > > Maybe add a note that the columns XX and YY were empty and therefore not > shown in the table, so that the unsavy reader is not confused. ) We have added the following sentence proceeding Tables 2 and 3. Please review. Current: Note that the Template and Trace columns are empty and therefore not included in the table. >> 17) <!--[rfced] What does "the draft" refer to in the sentence below? >> Should this be updated to "the draft message"? Note that there are >> other occurrences like the example listed below that are used throughout >> the appendices of this document. >> >> Original: >> It uses the Header Protection scheme from the draft. >> >> Perhaps: >> It uses the Header Protection scheme from the draft message. >> --> > > I guess you are refering to the occurances in Appendix C. > To my understanding those refer to this document (RFC-to-be 9788). > @DKG? > > Note: This text is also part of the autogenerated testvectors (i.e. those in > the grey boxes) in Appedix C, which MUST NOT be changed. This is due to > signature and encryption, i.e. signature and decryption will fail for those > using the test vectors, if edited. (If we wanted to change this, DKG would > need to reproduce the test vectors.) ) We strongly recommend that the test vectors be reproduced to have clearer and accurate wording. It is not apparent that "draft" is referring to this document, and once this document is published, using "draft" wouldn't be an accurate description. Perhaps: It uses the Header Protection scheme from this document. Note: If test vectors are reproduced, then instances of “header protection” could also be updated to “Header Protection” for consistency with the rest of the document. >> a) Please review each artwork element and let us know if any should be marked >> as sourcecode (or another element) instead. > > How can we find out which artwork element is marked with what? ) This can be viewed in the XML file provided below. >> b) Some artwork elements are marked as type "ascii-art" while others are >> not. Please review and let us know if there are any artwork elements you >> would >> like to have marked as "ascii-art". > > The only artworks I am aware of are the 3 figures in Appendix D. ) There are also artwork elements in Sections 1.9, 4.5.1, 4.5.2, 4.5.3.3, 4.10.1, 5.2.2, and 5.2.3, Appendix F.2, and throughout Appendices C and E. Note that it is also acceptable to leave the artwork elements blank. >> 20) <!-- [rfced] 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. > > Which sections are affected? ) Please see the XML file below to view the occurrences of <tt> and <em>. We note that <tt> is used in almost every section (beginning with Section 1.1 and ending in the Acknowledgements section) and <em> is used in Sections 4, 5.2.3, and 11.2 and Appendices B.3 and D.2.2. >> Additionally, we note variances with <tt>, for example, Bcc'ed vs. >> <tt>Bcc</tt>'ed. Please review let us know if any updates are needed >> for consistency. >> --> > > Which sections are affected? ) Section 11.4 uses both Bcc'ed and <tt>Bcc</tt>’ed. Please see this list of terms that use <tt> tags and let us know if there are any of these terms that are not tagged that you would like to add tags to for consistency: https://www.rfc-editor.org/authors/rfc9788-tt-sorted.txt >> 21) <!--[rfced] We note that the figures in the sections and appendices >> listed below are either misaligned slightly and/or have broken >> lines in the PDF output (the html and txt outputs display correctly). >> To avoid this issue, please let us know if replacing/redrawing >> the non-ASCII characters with ASCII characters is possible >> (this is commonly done for structure in YANG trees; see >> Section 5 of RFC 9731 as an example). Or if you have a >> different solution for a fix, please let us know. >> >> Misaligned: >> Section 1.9 >> Section 4.5.1 >> Section 4.5.2 >> Section 4.10.1 >> Appendices C.3.1-C.3.8 >> >> Broken Lines : >> Appendix C.1.3 >> Appendix C.1.5 >> Appendix C.1.6 >> Appendix C.1.7 >> Appendix C.1.8 >> Appendix C.2.2 >> Appendix C.2.3 >> Appendix C.2.4 >> Appendix C.2.5 >> Appendix C.2.6 >> Appendices C.3.9-C.3.17 >> --> > > Would such a change only affect the PDF version? ) Changes to the figures would appear in all three outputs (html, txt and pdf). >> 22) <!-- [rfced] Please review whether any of the notes in this document >> should be in the <aside> element. It is defined as "a container for >> content that is semantically less important or tangential to the >> content that surrounds it" >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> > > I am not aware of such notes. > @DKG @Alexey? ) Notes denoted by “Note:” can be seen in Sections 1.7, 4.4.1.1, 4.4.1.2, and 10.1.1 and Appendix F.2. Daniel and Alexey - Note that Bernie has explicitly requested your input on some of the updates/questions. We have updated per Bernie’s suggestions, but please review his previous emails and let us know if further updates are needed. — FILES (please refresh) — The files have been posted here: https://www.rfc-editor.org/authors/rfc9788.xml https://www.rfc-editor.org/authors/rfc9788.txt https://www.rfc-editor.org/authors/rfc9788.html https://www.rfc-editor.org/authors/rfc9788.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9788-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9788-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9788-auth48rfcdiff.html (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9788 Thank you, RFC Editor/ap > On May 29, 2025, at 9:00 AM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Authors, > > Thank you for your replies. We have updated as requested. Please note that > we have a number of follow-up comments/questions. > >>>> ) We have a couple of questions regarding the index. >>>> a. We note that there is a lot of index linking throughout the document. >>>> For it to be most useful, it is ideal that the index points to where the >>>> term is defined, and perhaps other key occurrences, not at each instance >>>> where the term is mentioned. Therefore, may we clean up the index to only >>>> link to definitions and key occurrences? For example, for “Header >>>> Confidentiality Policy” and “HCP”, we suggest only including links to >>>> Section 1.7 and Section 3, Paragraph 2, as these are where the terms are >>>> defined and expanded on. >>>> b. Within instances of “No Header Confidentiality Policy”, only “Header >>>> Confidentiality Policy” is linked. Was the intention to include an index >>>> entry for “No Header Confidentiality Policy” (if yes, we suggest including >>>> only one link to Section 3.2.3 (“No Header Confidentiality Policy”)), or >>>> may we remove the links from these occurrences? >>> DKG? >> >> No opinion. > > ) As Alexey and Bernie do not have any preference, we will await word from > Daniel regarding the questions about the index. Should Daniel have no > preference, we will streamline the index accordingly. > >> - Is it correct, that in the IANA registration section this RFC-to-be has >> no square brackets and a space betweeen "RFC" and its number, while >> referred RFC do? (In IANA registry, both are external references?) Or >> is this simply a typical case that is handled with by IANA in a standard >> process? >> >> Example (in section 12.2): >> >> | Content-Type | | MIME | | [RFC4021] and RFC 9788 | > > > ) Yes, it is correct and the style of the RFC Series to not have a linkable > citation to this document in the running text (as this document is not listed > as normative or informative in the References section). As self-references > are potentially confusing, they are listed with a space between "RFC" and the > number. Note that once this document is published, IANA will update its > registry with the RFC number and link to the published RFC. > >> * Section 3.4.2 (minor) >> >> [ TBD: (@RFC-Editor): Are mitigatable and mitigatory exchangeable terms? To >> me mitigatable (as originally )sounds more precise here, though unsure ] >> >> OLD >> >> An entry should not be marked as "Recommended" unless it has been >> shown to offer confidentiality or privacy improvements over the >> status quo and have minimal or mitigatory negative impact on messages >> deliverability and security. >> >> NEW: >> >> An entry should not be marked as "Recommended" unless it has been >> shown to offer confidentiality or privacy improvements over the >> status quo and have minimal or mitigatable negative impact on messages >> deliverability and security. > > ) Per Merriam-Webster, “mitigatory” is the adjective form of “mitigate”, and > “mitigatable” is not a word. However, it seems that “mitigable” was intended, > which is also an acceptable adjective form; the text now reflects “mitigable”. > > Also, it appears as if a section of the sentence was cut out in the OLD and > NEW text. Please let us know if you would like that section cut out. > > Current: > An entry should not be marked as "Recommended" unless it has been > shown to offer confidentiality or privacy improvements over the > status quo and have minimal or mitigable negative impact on messages > to which it is applied, considering factors such as message > deliverability and security. > >> 4.4.4 >> >> [ TBD (@RFC-Editor, @DKG, @Alexey): Not sure whether the comma preceding >> "or" is correctly set. Shouldn't this be like ] >> >> OLD: >> >> Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may >> populate the composer view using a combination of the referenced message's >> From, To, Cc, Reply-To, or Mail-Followup-To Header Fields or any other >> signals. >> >> >> NEW: >> Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may >> populate the composer view using a combination of the referenced message's >> From, To, Cc, Reply-To or Mail-Followup-To Header Fields, or any other >> signals. > > ) As “Header Fields” applies to “From”, “To”, “Cc”, “Reply-To”, and > “Mail-Followup-To”, we believe the commas in the OLD text are correct. > However, we could update as follows: > > Perhaps: > Depending on whether it is a Reply, a Reply All, or a Forward, an MUA > may populate the composer view using a combination of the referenced > message's From Header Field, To Header Field, Cc Header Field, Reply-To > Header Field, or Mail-Followup-To Header Field as well as any other signals. > >> * Appendix F.2. (minor) >> >> [ Note: The TXT version has the line break at an odd place. Suggest to >> remove the introduced hyphen.] >> >> OLD: >> >> Although the PEF-2 scheme is only meant to be used between PEF- >> 2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 >> (in which case, they typically render badly). >> >> NEW: >> >> Although the PEF-2 scheme is only meant to be used between PEF-2 >> compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 >> (in which case, they typically render badly). > > ) With the hyphen removed, may we further update the text as follows? > > Perhaps: > Although the PEF-2 scheme is only meant to be used between MUAs > compatible with PEF-2, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). > >>> 15) <!--[rfced] May we update "genericize" to "generalize"? >>> >>> Original: >>> So even if an >>> ambitious HCP opts to remove the human-readable part from any From >>> Header Field, and to standardize/genericize the local part of the >>> From address, the domain will still leak. >>> >>> Perhaps: >>> So even if an >>> ambitious HCP opts to remove the human-readable part from any From >>> Header Field, and to standardize/generalize the local part of the >>> From address, the domain will still leak. >>> --> >> >> No opinion. >> @DKG? > > ) As “genericize” is not listed in the Merriam-Webster dictionary and has not > been used in the RFC Series, we recommend updating it to “generalize”. Please > let us know if we may do so. > >>> b) FYI - We removed the blank columns from Tables 2 and 3. >> >> Maybe add a note that the columns XX and YY were empty and therefore not >> shown in the table, so that the unsavy reader is not confused. > > ) We have added the following sentence proceeding Tables 2 and 3. Please > review. > > Current: > Note that the Template and Trace columns are empty and therefore not > included in the table. > >>> 17) <!--[rfced] What does "the draft" refer to in the sentence below? >>> Should this be updated to "the draft message"? Note that there are >>> other occurrences like the example listed below that are used throughout >>> the appendices of this document. >>> >>> Original: >>> It uses the Header Protection scheme from the draft. >>> >>> Perhaps: >>> It uses the Header Protection scheme from the draft message. >>> --> >> >> I guess you are refering to the occurances in Appendix C. >> To my understanding those refer to this document (RFC-to-be 9788). >> @DKG? >> >> Note: This text is also part of the autogenerated testvectors (i.e. those in >> the grey boxes) in Appedix C, which MUST NOT be changed. This is due to >> signature and encryption, i.e. signature and decryption will fail for those >> using the test vectors, if edited. (If we wanted to change this, DKG would >> need to reproduce the test vectors.) > > ) We strongly recommend that the test vectors be reproduced to have clearer > and accurate wording. It is not apparent that "draft" is referring to this > document, and once this document is published, using "draft" wouldn't be an > accurate description. > > Perhaps: > It uses the Header Protection scheme from this document. > > Note: If test vectors are reproduced, then instances of “header protection” > could also be updated to “Header Protection” for consistency with the rest of > the document. > >>> a) Please review each artwork element and let us know if any should be >>> marked >>> as sourcecode (or another element) instead. >> >> How can we find out which artwork element is marked with what? > > ) This can be viewed in the XML file provided below. > >>> b) Some artwork elements are marked as type "ascii-art" while others are >>> not. Please review and let us know if there are any artwork elements you >>> would >>> like to have marked as "ascii-art". >> >> The only artworks I am aware of are the 3 figures in Appendix D. > > > ) There are also artwork elements in Sections 1.9, 4.5.1, 4.5.2, 4.5.3.3, > 4.10.1, 5.2.2, and 5.2.3, Appendix F.2, and throughout Appendices C and E. > Note that it is also acceptable to leave the artwork elements blank. > >>> 20) <!-- [rfced] 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. >> >> Which sections are affected? > > ) Please see the XML file below to view the occurrences of <tt> and <em>. We > note that <tt> is used in almost every section (beginning with Section 1.1 > and ending in the Acknowledgements section) and <em> is used in Sections 4, > 5.2.3, and 11.2 and Appendices B.3 and D.2.2. > >>> Additionally, we note variances with <tt>, for example, Bcc'ed vs. >>> <tt>Bcc</tt>'ed. Please review let us know if any updates are needed >>> for consistency. >>> --> >> >> Which sections are affected? > > ) Section 11.4 uses both Bcc'ed and <tt>Bcc</tt>’ed. > > Please see this list of terms that use <tt> tags and let us know if there are > any of these terms that are not tagged that you would like to add tags to for > consistency: > https://www.rfc-editor.org/authors/rfc9788-tt-sorted.txt > >>> 21) <!--[rfced] We note that the figures in the sections and appendices >>> listed below are either misaligned slightly and/or have broken >>> lines in the PDF output (the html and txt outputs display correctly). >>> To avoid this issue, please let us know if replacing/redrawing >>> the non-ASCII characters with ASCII characters is possible >>> (this is commonly done for structure in YANG trees; see >>> Section 5 of RFC 9731 as an example). Or if you have a >>> different solution for a fix, please let us know. >>> >>> Misaligned: >>> Section 1.9 >>> Section 4.5.1 >>> Section 4.5.2 >>> Section 4.10.1 >>> Appendices C.3.1-C.3.8 >>> >>> Broken Lines : >>> Appendix C.1.3 >>> Appendix C.1.5 >>> Appendix C.1.6 >>> Appendix C.1.7 >>> Appendix C.1.8 >>> Appendix C.2.2 >>> Appendix C.2.3 >>> Appendix C.2.4 >>> Appendix C.2.5 >>> Appendix C.2.6 >>> Appendices C.3.9-C.3.17 >>> --> >> >> Would such a change only affect the PDF version? > > ) Changes to the figures would appear in all three outputs (html, txt and > pdf). > >>> 22) <!-- [rfced] Please review whether any of the notes in this document >>> should be in the <aside> element. It is defined as "a container for >>> content that is semantically less important or tangential to the >>> content that surrounds it" >>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>> --> >> >> I am not aware of such notes. >> @DKG @Alexey? > > ) Notes denoted by “Note:” can be seen in Sections 1.7, 4.4.1.1, 4.4.1.2, and > 10.1.1 and Appendix F.2. > > > Daniel and Alexey - Note that Bernie has explicitly requested your input on > some of the updates/questions. We have updated per Bernie’s suggestions, but > please review his previous emails and let us know if further updates are > needed. > > > — FILES (please refresh) — > > The files have been posted here: > https://www.rfc-editor.org/authors/rfc9788.xml > https://www.rfc-editor.org/authors/rfc9788.txt > https://www.rfc-editor.org/authors/rfc9788.html > https://www.rfc-editor.org/authors/rfc9788.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9788-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9788-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version to > this one) > https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff between > last version and this) > > 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 AUTH48 status page > below prior to moving this document forward in the publicationprocess. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9788 > > Thank you, > RFC Editor/ap > > > >> On May 23, 2025, at 1:35 PM, Bernie Hoeneisen <ber...@ietf.hoeneisen.ch> >> wrote: >> >> Dear RFC Editor, Co-authors et al. >> >> Below you can find my 2nd batch of findings in RFC-to-be 9788 while going >> through the RFC-Editor changes. Some of the finding are just hints to my >> co-authors to look at certain edits that likely need reverting or >> adjustments. >> >> Note that those findings / change requests marked with "TBD" need >> clarification, either by the RFC Editor or the co-authors (as tagged in the >> comments). >> >> All the best, >> Bernie >> >> >> -------------------------- >> >> >> * section 1.2 (minor) >> >> [ TBD (@RFC-Editor): Why was the hyphen removed? My dictionary suggest using >> a hyphen in this case. Is this difference in the dictionary used by the >> RFC-Editor? ] >> >> OLD: >> >> Producing a signed-only message using this specification is risk free. >> >> NEW: >> >> Producing a signed-only message using this specification is risk-free. >> >> >> * Section 3.4.2 (minor) >> >> [ TBD: (@RFC-Editor): Are mitigatable and mitigatory exchangeable terms? To >> me mitigatable (as originally )sounds more precise here, though unsure ] >> >> OLD >> >> An entry should not be marked as "Recommended" unless it has been >> shown to offer confidentiality or privacy improvements over the >> status quo and have minimal or mitigatory negative impact on messages >> deliverability and security. >> >> NEW: >> >> An entry should not be marked as "Recommended" unless it has been >> shown to offer confidentiality or privacy improvements over the >> status quo and have minimal or mitigatable negative impact on messages >> deliverability and security. >> >> >> * Section 4.2 >> >> [ TBD (@DKG): Is this equivalent to what you want to express here? ] >> >> OLD: >> >> It outputs a pair of lists of (h,v) Header Fields. >> >> NEW: >> >> It produces as output a pair of lists of (h,v) Header Fields. >> >> >> >> * Section 4.3.1 >> >> [ TBD (@DKG): Is skipping the explicit "if"s appropriate in the pseudo code? >> ] >> >> OLD: >> >> 6. If the message is encrypted, ct has a parameter hp="cipher", and (h,v) >> is not in refouter: >> >> NEW >> >> 6. If the message is encrypted, and if ct has a parameter hp="cipher", and >> if (h,v) is not in refouter: >> >> >> --- >> >> [Note @DKG: The original did not contain the comma and the 2nd "return" ] >> >> OLD: >> >> i. Return signed-and-encrypted if is_sig_valid is otherwise encrypted-only. >> >> >> NEW: >> >> i. Return signed-and-encrypted if is_sig_valid, otherwise return >> encrypted-only. >> >> >> ---- >> >> [Note @DKG: The original did not contain the comma and the 2nd "return" ] >> >> OLD: >> >> 7. Return signed-only if is_sig_valid is otherwise unprotected. >> >> >> NEW: >> >> 7. Return signed-only if is_sig_valid, otherwise return unprotected. >> >> >> * Section 4.4.1.2. >> >> [ TBD (@RFC-Editor): Suggest to either let all "or"s in (as originally) or >> remove all "or"s, e.g. ] >> >> OLD: >> >> * the message has a broken signature, >> >> * the message has a broken signature, or >> >> * the message has a valid signature, but the receiving MUA does not >> see any valid binding between the signing certificate and the >> addr-spec of the inner From Header Field. >> >> NEW: >> >> * the message has a broken signature >> >> * the message has a broken signature >> >> * the message has a valid signature, but the receiving MUA does not >> see any valid binding between the signing certificate and the >> addr-spec of the inner From Header Field >> >> >> * Sections 4.4.2 and Section 4.4.3 >> >> [ I would prefer to keep the "and" (as originally), to stress out, that both >> conditions must be met. ] >> >> OLD: >> >> * From Header Field Mismatch (as defined in Section 4.4.1.1), and >> >> * No Valid and Correctly Bound Signature (as defined in >> Section 4.4.1.2). >> >> NEW: >> >> * From Header Field Mismatch (as defined in Section 4.4.1.1), and >> >> * No Valid and Correctly Bound Signature (as defined in >> Section 4.4.1.2). >> >> >> 4.4.4 >> >> [ TBD (@RFC-Editor, @DKG, @Alexey): Not sure whether the comma preceding >> "or" is correctly set. Shouldn't this be like ] >> >> OLD: >> >> Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may >> populate the composer view using a combination of the referenced message's >> From, To, Cc, Reply-To, or Mail-Followup-To Header Fields or any other >> signals. >> >> >> NEW: >> Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may >> populate the composer view using a combination of the referenced message's >> From, To, Cc, Reply-To or Mail-Followup-To Header Fields, or any other >> signals. >> >> >> * Section 4.4.5 >> >> [ TBD (@Alexey): This original version contained "[...] A-label form is >> described [...]". I guess you menat "as described" ] >> >> OLD: >> >> If it does, it MUST be converted to the A-label form, which is described in >> [RFC5891]. >> >> NEW: >> >> If it does, it MUST be converted to the A-label form as described in >> [RFC5891]. >> >> >> * Section 4.6 >> >> OLD: >> >> In another example, Section 6.2 notes that the value of the Reply-To field >> can influence the draft reply message. >> >> NEW: >> >> In another example, Section 6.2 notes that the value of the Reply-To Header >> Field can influence the draft reply message. >> >> >> * Section 5.2.2 >> >> [ Note: The Legacy Dislay Element may consist of several lines, correct as >> it was originally ] >> >> OLD: >> >> Note that the Legacy Display Elements (the lines beginning with >> Subject: and Cc:) are part of the body of the MIME part in question. >> >> NEW: >> >> Note that the Legacy Display Element (the lines beginning with >> Subject: and Cc:) are part of the body of the MIME part in question. >> >> >> * Section 6.1 >> >> [Note: slight change in semantics using the hyphen, better as it was >> originally] >> >> OLD: >> >> If the Header Field's value is unchanged, the composing MUA regenerates the >> Header Field using the Header Fields that had been on the outside of the >> original message at sending time. >> >> NEW: >> >> If the Header Field's value is unchanged, the composing MUA re-generates the >> Header Field using the Header Fields that had been on the outside of the >> original message at sending time. >> >> >> * Section 6.1.1 >> >> @DKG: Please verify that the edits have not changed the semantics in the >> paragraphe "[...] * A built-in MUA respond [...] >> >> @DKG: I am almost certain that the edits around "8. Return a new HCP from >> confmap that tests whether [...]" need to be reverted in part. Please check! >> >> >> * Section 6.2 >> >> @DKG, @Alexey: "Replay" was changed to "Relay". I think this should be >> reverted. Any thought? >> >> >> * Section 7.1 >> >> OLD: >> >> An MUA that receives a message with Header Protection that contains these >> Header Fields in the unprotected section and that has reason to believe the >> message is coming through a mailing list MAY decide to render them to the >> user (explicitly or implicitly) even though they are not protected. >> >> NEW: >> >> An MUA that receives a message with Header Protection that contains these >> Header Fields in the unprotected Header Section and that has reason to >> believe the message is coming through a mailing list MAY decide to render >> them to the user (explicitly or implicitly) even though they are not >> protected. >> >> >> * Section 11.2.2 >> >> @DKG, @Alexey: Not sure whether or not the edits around "mailbox" are >> correct. Any thoughts? >> >> >> * Section 12.3 >> >> @DKG, @Alexey: The following sentence has not been added to the IANA >> registry as requested: >> >> "Note that during IETF Review, the designated expert must be consulted. >> Guidance for the designated expert can be found in Section 3.4.2." >> >> Are we fine with this? >> >> >> * Appendix F.2. (minor) >> >> [ Note: The TXT version has the line break at an odd place. Suggest to >> remove the introduced hyphen.] >> >> OLD: >> >> Although the PEF-2 scheme is only meant to be used between PEF- >> 2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 >> (in which case, they typically render badly). >> >> NEW: >> >> Although the PEF-2 scheme is only meant to be used between PEF-2 >> compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 >> (in which case, they typically render badly). >> >> >> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
