Dear RFC Editor,
Replying to some of your questions/comments, where I have an opinion:
On 21/05/2025 02:07, rfc-edi...@rfc-editor.org wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
[...]
14) <!-- [rfced] We note that there are no instances of "Content-Type:
message/global"
in RFC 5355. Please review and let us know if/how this citation should be
updated.
Original:
An incoming e-mail message may include an attached forwarded message,
typically as a MIME subpart with Content-Type: message/rfc822
([RFC5322]) or Content-Type: message/global ([RFC5355]).
-->
Use RFC 6532 for message/global.
15) <!--[rfced] We note that both "conformant rendering MUA" and "conformant
composing MUA" are used in the document. Should this phrasing be made
consistent?
Rendering MUA is the receiving side, while composing MUA is the sending
side.
Original:
A conformant rendering MUA MUST NOT conflate the cryptographic
protections of the forwarded message with the cryptographic
protections of the incoming message.
...
A conformant rendering MUA MAY render a Cryptographic Summary of the
protections afforded to the forwarded message by its own
Cryptographic Envelope...
...
a conformant composing MUA should consider that multiple parts might
be rendered as the Main Body Part when the message is ultimately viewed.
-->
16) <!--[rfced] To improve readability, may we update "prefer" to "choose"?
Original:
An MUA MAY offer the user a mechanism to prefer a particular MIME
type within multipart/alternative instead of the last renderable
child.
Perhaps:
An MUA MAY offer the user a mechanism to choose a particular MIME
type within multipart/alternative instead of the last renderable
child.
-->
I am not sure. As long as we are clear that "choose" doesn't mean a pop
up asking user to choose, that is probably Ok.
17) <!--[rfced] To clarify "to avoid possible cross-protocol key misuse", may
we update this sentence as follows?
Original:
A conformant MUA that generates S/MIME certificates for the user MUST
generate distinct S/MIME certificates: one for encryption and another
for signing, to avoid possible cross-protocol key misuse.
Perhaps:
A conformant MUA that generates S/MIME certificates for the user MUST
also generate distinct S/MIME certificates to avoid possible cross-protocol
key misuse: one for encryption and another for signing.
-->
Looks good to me.
18) <!--[rfced] May we expand "certs" to "certificates" in the text below?
Original:
...and intermediate certification authority certificates that
permit chaining from the end entity certs to widely-accepted trust
anchors.
...
A future version of this document may describe in more
detail how these incoming certs should be handled.
...
Such discussion should address privacy concerns: what information
leaks to whom when checking peer cert revocations?
-->
Yes.
23) <!--[rfced] Should this list item be phrased as a question to match
the other list items in Section 9.4?
Original:
* Section 3.6.3 of [RFC5322] describes a set of choices about
whether (and how) to populate the Bcc field explicitly on Bcc'ed
copies of the message, and in the copy stored in the sender's Sent
folder.
Perhaps:
* Should the Bcc field be populated explicitly on Bcc'ed copies
I think "Bcc Header Field".
of the message and in the copy stored in the sender's Sent
folder? See Section 3.6.3 of [RFC5322] for a set of choices.
-->
29) <!--[rfced] Terminology
c) FYI - We updated this document to reflect the forms on the right for
consistency with the companion document and the RFC Series. Please let
us know of any objections.
e-mail -> email
smartcards -> smart cards
No objections from me.
d) May we update "mail user agent" to "Mail User Agent (MUA)" on the
first mention (in the Abstract) and use "MUA" thereafter (as
recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
Yes.
Additionally, may we make the following update for conciseness?
Original:
* _MUA_ is short for Mail User Agent; an e-mail client.
Perhaps:
* The _Mail User Agent (MUA)_ is an email client.
-->
Sure.
Best Regards,
Alexey
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
