Hi Alanna, Alexey, et al.
Below (inline) my comments on the discussions between Alanna and Alexey.
(I intend to send further feedback in separate emails.)
On Fri, 23 May 2025, Alexey Melnikov wrote:
Hi Alanna,
On 22/05/2025 18:50, Alanna Paloma wrote:
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.
No, this doesn't read right.
The original is using "Legacy receiving MUA", which is a "receiving MUA"
which is Legacy. Does this help?
+1
Maybe "Legacy (receiving) MUA"?
I think the original is fairly clear as "receiving MUA" is a good
description on what we want to express. i.e. sth like "An MUA in its role
of receiving email messages". (IIRC, "receiving MUA/side/client" are used
also elsewhere in the document.) I am not quite sure what is the
motivation for changing this. I would suggest to leave it as in the
original are maybe replace "client" by MUA at the end, as in the
following:
The message generation guidance aims to minimize negative
interactions with any Legacy receiving MUA while providing
actionable cryptographic properties for modern receiving 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...
This looks better to me, but I would like to hear from DKG/Bernie on this
first.
Works for me (remove "MIME").
) 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.
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.
Best Regards,
Alexey
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.
Fine with me.
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.
see above.
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.
Alexey's suggestion is fine with me.
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.
I trust Alexey here.
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.
see above.
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.
I trust Alexey here.
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.
Yes.
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.
Support Alexey here, to keep matters clear for the readers.
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?
This is part of a wider issue, I am currently looking at, e.g. using the
definitions consistently and in same case (upper case first letter), i.e.
1) Header Field / Header Section instead of header, as defined in terms
section.
--> I tried to catch these cases and will send it soon
2) Maintaining case throughout the document, if and as a term is defined
in section "1.7. Terms" (e.g. first letter upper case) and is referring to
the definition. However, there are exexptions, including anything that is
part of an autogenerated testvector (grey boxes in html version of the
this RFC-to-be in Appendix C) MUST NOT be changed, as it would break the
signature and/or encryption of the testvector.
For example Replace "header protection" by "Header Protection" (execept
inside autogenerated test vectors).
--> Is this something the RFC Editor can handle or do we need to send each
occurance?
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?
Support Alexeys suggestion.
Alternative could be:
3.1.1. HCP Avoids Changing addr-spec of From Header Field
Both is fine with me.
Best,
Bernie
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
