Hi Bernie, This is a friendly reminder that we await your review and approval of the updated files prior to moving this document forward in the publication process.
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 (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9787-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc9787-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9787 Thank you, RFC Editor/ap > On Jun 17, 2025, at 6:10 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > Hi Alanna-- > > On Tue 2025-06-17 14:45:32 -0700, Alanna Paloma wrote: > >> Thank you for the updated XML file. The other document files have been >> updated accordingly. > > Thanks for processing it! > >>> 1) "conformant-receiving MUA" or "conformant-interpreting MUA", etc: >>> the RFC editor has hyphenated terms like "conformant receiving MUA". >>> My understanding of hyphenation in this case implies that the >>> adjectives belong together, rather than applying independently to >>> the noun they modify. However, i think that we're talking about an >>> MUA that is conformant with this draft, and is also receiving a >>> message (for example). So i would generally prefer the original >>> "conformant receiving MUA" or (if you prefer) "receiving conformant >>> MUA" or even "a conformant MUA that receives the message". >>> >>> This appears multiple times in the document, search for "conformant-" >> >> ) Thank you for that clarification. We have reverted these changes to remove >> the hyphen. > > looks good. > >>> 2) This sentence: >>> >>> If the application wants to generate a message that is both >>> encrypted and signed, it MAY use the simple MIME structure from >>> Section 4.1.2.2 by ensuring that the Encrypted Message [RFC9580] >>> within the application/octet-stream part contains a Signed >>> Message [RFC9580] (the final option described in Section >>> 4.1.2.2). >>> >>> was originally written as "RFC9580 Encrypted Message" and "RFC9580 >>> Signed Message", but the RFC editor has moved the reference to after >>> the term. The term is used here in the sense that it refers to >>> Section 10.3 of RFC 9580, the OpenPGP Message grammar. The term >>> "Encrypted Message" is very generic, so in common conversation, you >>> might call it an "RFC9580 Encrypted Message" to ensure that it's not >>> generic. It feels clumsy to call it an "Encrypted Message [RFC9580]". >> >> ) We have also reverted these changes. >> >> Current: >> If the application wants to generate a message that is both encrypted >> and signed, it MAY use the simple MIME structure from Section 4.1.2.2 >> by ensuring that the [RFC9580] Encrypted Message within the >> application/octet-stream part contains a [RFC9580] Signed Message >> (the final option described in Section 4.1.2.2). > > I read this out loud and i think that "a [RFC9580] Signed Message" might > be better written as "an [RFC9580] Signed Message", because i pronounce > it "arr eff see". But i'm fine with using "a" instead of "an" if that's > the RFC editor's preference. > > I also note your updates to mark the MIME tree structures as > "ascii-art", which look correct to me. > > Thanks for your work on this! I am satisfied with RFC-to-be 9787. > > Regards, > > --dkg -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
