Hi Alexey and other authors, We have updated the files per Alexey’s response. Please note that some of our initial questions have not been addressed and we have follow-up questions.
>> 7) <!--[rfced] For clarity and consistency, may we update the phrasing of >> "Legacy receiving MUA" and "modern receiving clients" as follows? >> >> Original: >> The message generation guidance aims to minimize negative >> interactions with any Legacy receiving MUA while providing >> actionable cryptographic properties for modern receiving >> clients. >> >> Perhaps: >> The message generation guidance aims to minimize negative >> interactions with any Legacy MUA recipient while providing >> actionable cryptographic properties for modern client >> recipients. >> --> > Slight change in meaning. We are not typically talking about legacy > recipients, as any recipient can have a mixture of MUAs, some legacy and some > not. ) We have tweaked the text further. Does the sentence below retain the intended meaning? Perhaps: The message generation guidance aims to minimize negative interactions with any Legacy MUA being received while providing actionable cryptographic properties for clients receiving modern MUAs. >> 12) <!--[rfced] As "Main Body Part" is a term used throughout the document, >> may we >> update this sentence as shown below? >> >> Original: >> The purpose of injecting a Legacy Display Element into each Main Body >> MIME part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> >> Perhaps: >> The purpose of injecting a Legacy Display Element into each MIME Main >> Body Part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> --> > Do we need to say "MIME" above? Reads odd in both cases. ) With “MIME” removed, may we update this sentence as follows? Perhaps: The purpose of injecting a Legacy Display Element into each Main Body Part is to enable rendering of otherwise obscured Header Fields in Legacy MUAs that are capable of message decryption... ) 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? The files have been posted here (please refresh): 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 (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 AUTH48 status page below prior to moving this document forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9788 Thank you, RFC Editor/ap > On May 21, 2025, at 9:49 AM, Alexey Melnikov <alexey.melni...@isode.com> > wrote: > > Dear RFC Editor, > Thank you for your work! > I am replying to some of your questions/suggestions, mostly where I disagree > with your suggestions: > On 21/05/2025 02:19, rfc-edi...@rfc-editor.org wrote: >> 4) <!--[rfced] To reflect how their usage is described in RFC 8126, we >> have updated "key words" to "policies" and "SPECIFICATION >> REQUIRED" and "IETF REVIEW" to "Specification Required" and "IETF >> Review", respectively (i.e., we capitalized only the first letter >> of each word and removed <bcp14> tags around "REQUIRED" in the >> XML). Note that all occurrences of these terms have been made >> lowercase. >> >> Additionally, may we move this text from the "Requirements Language" >> section to the "Terms" section as the first paragraph since these >> terms are not key words? >> >> One example >> >> Original: >> The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear >> in this document when used to describe namespace allocation are to be >> interpreted as described in [RFC8126]. >> >> Current: >> The policies "Specification Required" and "IETF Review" that appear >> in this document when used to describe namespace allocation are to be >> interpreted as described in [RFC8126]. >> --> > Good idea. >> >> 7) <!--[rfced] For clarity and consistency, may we update the phrasing of >> "Legacy receiving MUA" and "modern receiving clients" as follows? >> >> Original: >> The message generation guidance aims to minimize negative >> interactions with any Legacy receiving MUA while providing >> actionable cryptographic properties for modern receiving >> clients. >> >> Perhaps: >> The message generation guidance aims to minimize negative >> interactions with any Legacy MUA recipient while providing >> actionable cryptographic properties for modern client >> recipients. >> --> > Slight change in meaning. We are not typically talking about legacy > recipients, as any recipient can have a mixture of MUAs, some legacy and some > not. >> >> 10) <!--[rfced] To make this sentence more concise, may we remove "of the >> part"? >> >> Original: >> * Discard the leading lines of the body of the part up to and >> including the first entirely blank line. > Would "of the body part up to ..." be better? I think that is what was > intended. >> >> Perhaps: >> * Discard the leading lines of the body up to and including the >> first entirely blank line. >> --> >> >> >> 11) <!--[rfced] The <artwork> in Sections 5.2.2 and 5.2.3 includes the >> following attributes: charset=UTF-8 and hp-legacy-display=1. >> >> Should quotes appear around the "UTF-8" and "1" values in these >> instances per other use in the document? And should "UTF-8" be made >> lowercase for consistency, or are the lowercase instances different? >> >> Current: >> Content-Type: text/plain; charset=UTF-8 vs. >> Content-Type: text/plain; charset="utf-8" >> >> Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; vs. >> Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 >> --> > Both forms are semantically equivalent. I prefer to have a mixture to show > implementors that both are allowed. >> >> 12) <!--[rfced] As "Main Body Part" is a term used throughout the document, >> may we >> update this sentence as shown below? >> >> Original: >> The purpose of injecting a Legacy Display Element into each Main Body >> MIME part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> >> Perhaps: >> The purpose of injecting a Legacy Display Element into each MIME Main >> Body Part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> --> > Do we need to say "MIME" above? Reads odd in both cases. >> >> 13) <!--[rfced] Is a "mail transport system" the same thing as a "mail >> transport >> agent"? If so, may we update this sentence to use "mail transport agents" >> for consistency with the rest of the document? > It is not. "Mail Transport System" is a collection of "Mail Transport Agents" > that cooperate to provide mail transport. >> >> Original: >> In the future, some mail transport systems may accept and deliver >> messages with even less publicly visible metadata. >> >> Perhaps: >> In the future, some mail transport agents may accept and deliver >> messages with even less publicly visible metadata. >> --> >> >> > >> b) For the following terms, both the expansion and the acronym are >> used throughout the document. Would you like to use the expansion >> upon the first mention and the acronym for the rest of the document >> for consistency as recommended in the Web Portion of the Style Guide >> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>? >> >> Header Confidentiality Policy (HCP) >> Mail User Agent (MUA) > Yes, please. >> 25) <!--[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. >> >> For example, please consider whether the following should be updated: >> - dummy >> - man in the middle >> - whitespace > "whitespace" is a well known term in email and there is no alternative. I > prefer to keep it as is. > > Also a few other comments: > 1) In Section 1.7 (Terms) you lowercases "Message" and "Body" in various > definitions. While the end result is still understandable, the intent was for > different definitions to reference to each other, so I think I prefer the > original version. DKG/Bernie? > 2) Section title for 3.1.1. You changed "HCP Avoids Changing From addr-spec" > to "HCP Avoids Changing from addr-spec". This is actually change of meaning. > Maybe it should have been "From Header Field addr-spec" for clarity? > Best Regards, > Alexey > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
