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
