Hi Alexey and other authors, We have updated the files per Alexey's response. Please note that 19 questions have not yet been addressed and we have a follow-up question.
>> 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. ) Does this sentence retain the intended meaning (updated “offer” to “allow”)? Perhaps: An MUA MAY allow the user a mechanism to choose a particular MIME type within multipart/alternative instead of the last renderable child. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9787.xml https://www.rfc-editor.org/authors/rfc9787.txt https://www.rfc-editor.org/authors/rfc9787.html https://www.rfc-editor.org/authors/rfc9787.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9787-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9787-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9787-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/rfc9787 Thank you, RFC Editor/ap > On May 21, 2025, at 10:45 AM, Alexey Melnikov <alexey.melni...@isode.com> > wrote: > > 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
