Hi DKG, Thank you for the updated XML file. The other document files have been updated accordingly.
> 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. > 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). — FILES (please refresh) — The files have been posted here: 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) Thank you, RFC Editor/ap > On Jun 17, 2025, at 8:46 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > Hi RFC Editors-- > > I know i've already given my OK for RFC-to-be 9787, but i just did a > much closer read, and found a number of small changes that i think > improve the document. > > I'm attaching a revised rfc9787.xml, which contains these minor changes, > which i think are self-explanatory, but i'm also happy to answer any > questions about them. > > In addition, i have two things that i don't know exactly how to resolve, > but would appreciate feedback on: > > 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-" > > 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]". > > > Any suggestions for how to deal with these two additional concerns? If we > decide to not change anything for either of them, i'll survive -- just > wanted to make sure the RFC editor understands and is aware of them. > > Regards, > > --dkg > > > <rfc9787.xml> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
