Hi Bernie, This is another friendly reminder that we are awaiting the additional editorial changes for both RFCs-to-be 9787 and 9788. Once we receive these changes, we will update each document accordingly for your review.
Best regards, RFC Editor/ap > On Aug 6, 2025, at 8:34 AM, Bernie Hoeneisen <ber...@ietf.hoeneisen.ch> wrote: > > Dear Alenna > > Status Update: I am currently awaiting a response from our lead author > regarding the latest editorial changes (for both documents 9787/9788). I > expect you to get the latest revisions shortly. > > cheers > Bernie > > -- > > http://ucom.ch/ > Modern Telephony Solutions and Tech Consulting for Internet Technology > > > On Wed, 6 Aug 2025, Alanna Paloma wrote: > >> Hi Bernie, >> >> This is a friendly reminder that we await your review and approval of the >> updated files. Once we receive your approval, we will move this document >> forward in the publication process. >> >> — FILES (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 >> >> 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 (AUTH48 >> changes side by side) >> https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version to >> this one) >> https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff between >> last version and this) >> >> Please see the AUTH48 status page for this document here: >> https://www.rfc-editor.org/auth48/rfc9788 >> >> Thank you, >> RFC Editor/ap >> >>> On Jul 30, 2025, at 11:21 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >>> wrote: >>> >>> Hi Roman, >>> >>> Thank you for the follow up. Your approval has been noted: >>> https://www.rfc-editor.org/auth48/rfc9788 >>> >>> Best regards, >>> RFC Editor/ap >>> >>>> On Jul 30, 2025, at 10:33 AM, Roman Danyliw <r...@cert.org> wrote: >>>> >>>> Hi Alanna! >>>> >>>> Having heard no objections to the new normative language per >>>> https://mailarchive.ietf.org/arch/msg/spasm/qDR0QqnPphZhTJGcN-zVuNwu8rc/, >>>> I approve the changes to this document. >>>> >>>> Roman >>>> >>>> -----Original Message----- >>>> From: Roman Danyliw >>>> Sent: Thursday, July 17, 2025 1:09 PM >>>> To: Alanna Paloma <apal...@staff.rfc-editor.org> >>>> Cc: Daniel Kahn Gillmor <d...@fifthhorseman.net>; Bernie Hoeneisen >>>> <ber...@ietf.hoeneisen.ch>; Alexey Melnikov <alexey.melni...@isode.com>; >>>> rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; Russ >>>> Housley <hous...@vigilsec.com>; auth48archive >>>> <auth48archive@rfc-editor.org> >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9788 >>>> <draft-ietf-lamps-header-protection-25> for your review >>>> >>>> For situational awareness, I've reached out to the LAMPS WG to confirm >>>> there are no objections to the introduction of new normative language with >>>> the keywords in Section 10.*. I'll respond on Tuesday, July 29 with the >>>> way ahead after this call for input closes. >>>> >>>> Roman >>>> >>>> -----Original Message----- >>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>>> Sent: Wednesday, July 16, 2025 3:07 PM >>>> To: Roman Danyliw <r...@cert.org> >>>> Cc: Daniel Kahn Gillmor <d...@fifthhorseman.net>; Bernie Hoeneisen >>>> <ber...@ietf.hoeneisen.ch>; Alexey Melnikov <alexey.melni...@isode.com>; >>>> rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; Russ >>>> Housley <hous...@vigilsec.com>; auth48archive >>>> <auth48archive@rfc-editor.org> >>>> Subject: Re: [AD] AUTH48: RFC-to-be 9788 >>>> <draft-ietf-lamps-header-protection-25> for your review >>>> >>>> Warning: External Sender - do not click links or open attachments unless >>>> you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi Roman, >>>> >>>> Apologies for that! The link should be working now. >>>> >>>> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html >>>> >>>> RFC Editor/ap >>>> >>>>> On Jul 16, 2025, at 10:49 AM, Roman Danyliw <r...@cert.org> wrote: >>>>> >>>>> Hi! >>>>> >>>>> I was trying to review the diff but >>>>> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html returned a 404 >>>>> error? Should I look elsewhere, or is there a glitch? >>>>> >>>>> Roman >>>>> >>>>> -----Original Message----- >>>>> From: Alanna Paloma <apal...@staff.rfc-editor.org> >>>>> Sent: Wednesday, July 16, 2025 1:07 PM >>>>> To: Roman Danyliw <r...@cert.org>; Daniel Kahn Gillmor >>>>> <d...@fifthhorseman.net>; Bernie Hoeneisen <ber...@ietf.hoeneisen.ch>; >>>>> Alexey Melnikov <alexey.melni...@isode.com> >>>>> Cc: rfc-edi...@rfc-editor.org; lamps-...@ietf.org; >>>>> lamps-cha...@ietf.org; Russ Housley <hous...@vigilsec.com>; >>>>> auth48archive <auth48archive@rfc-editor.org> >>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9788 >>>>> <draft-ietf-lamps-header-protection-25> for your review >>>>> >>>>> Warning: External Sender - do not click links or open attachments unless >>>>> you recognize the sender and know the content is safe. >>>>> >>>>> >>>>> Hi Authors and Roman*, >>>>> >>>>> *Roman - As the AD, please review and approve the following changes: >>>>> - Section 1.2: added text >>>>> - Section 1.4: added text >>>>> - Section 4.2: updated text >>>>> - Section 5.2.1: deleted text >>>>> - Section 6.1: updated text (including removal of keyword “MUST”) >>>>> - Section 6.1.1: added section with new text >>>>> - Section 6.1.2: added and updated text >>>>> - Section 7.1: added text >>>>> - Section 10.1: updated text >>>>> - Section 10.2: added keywords “MUST” and “MUST NOT” >>>>> - Section 10.3: added keywords “SHOULD” and “MUST” >>>>> - Section 10.4: added text >>>>> >>>>> See this diff file for the changes: >>>>> https://www.rfc-editor.org/authors/rfc9788-ad-diff.html >>>>> >>>>> >>>>> Authors - Thank you for your reply. We have updated the files as >>>>> requested. >>>>> >>>>>> 1) In Section 1.1 ("Update to RFC 8551"), the rendered plain text >>>>>> version of the document appears to split "message/rfc822" across two >>>>>> lines, with the line break coming immediately after the "/" (U+002F >>>>>> SOLIDUS). The authors would prefer it if there was no line break in >>>>>> that string, but we don't know how to coax that behavior out of the >>>>>> XML input format. (there is no problem in the HTML output, but the >>>>>> PDF output may also have the same problem) Can you help us fix this? >>>>> >>>>> ) We have fixed this issue. >>>>> >>>>>> 2) In the course of the review, we realized that the document uses >>>>>> the terms "send" and "compose" somewhat interchangably, and likewise >>>>>> also "receive" and "render" somewhat interchangeably. While we >>>>>> think the XML included here is understandable as-is, we think it >>>>>> might be cleaner to try to use use "compose" more regularly for the >>>>>> message generation side and "render" more regularly for the message >>>>>> interpretation side. We have prepared an additional update to the >>>>>> XML that applies this change, but it's a fairly large change >>>>>> size-wise, since "send" and "receive" are relatively common words in >>>>>> the document. If you think our using "compose" and "render" more >>>>>> consistently throughout the document (instead of "send" and >>>>>> "receive") is worthwhile, please let us know. I can send you a >>>>>> version of the XML with that change applied as well. If you're OK >>>>>> with it as-is, we can live with it as-is too. >>>>> >>>>> ) As the text seems understandable and clear enough to readers as-is, we >>>>> defer to your preference if you would like “send”/“compose” and >>>>> “receive”/“render” to be made more consistent throughout the document. >>>>> Since you already made those updates in another XML file, we can easily >>>>> update the other document files to match if you do choose to make these >>>>> changes. >>>>> >>>>>> 3) Finally, the MIME structure diagram misalignment in PDF that we >>>>>> are wrestling with in RFC-to-be 9787 also appears to apply to this >>>>>> draft. >>>>>> With the recent changes to xml2rfc >>>>>> (https://github.com/ietf-tools/xml2rfc/pull/1261) i think we can >>>>>> resolve this by switching to an entirely BOX DRAWINGS approach, as >>>>>> with 9787. Let us know if that's your preference, or if you'd rather >>>>>> we do something else with those diagrams. >>>>> >>>>> ) As DKG’s PR to add Noto Sans Mono >>>>> (https://github.com/ietf-tools/xml2rfc/pull/1261) has been merged into >>>>> main, we are awaiting the next release of xml2rfc, which will likely be >>>>> later this week. To be consistent with 9787, please send us and updated >>>>> XML with BOX DRAWINGS. >>>>> >>>>> --- >>>>> 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 (AUTH48 >>>>> changes side by side) >>>>> https://www.rfc-editor.org/authors/rfc9788-lastdiff.html (last version >>>>> to this one) >>>>> https://www.rfc-editor.org/authors/rfc9788-lastrfcdiff.html (rfcdiff >>>>> between last version and this) >>>>> >>>>> We will await the updated XML file as well as approvals from Bernie and >>>>> *Roman. >>>>> >>>>> Please see the AUTH48 status page for this document here: >>>>> https://www.rfc-editor.org/auth48/rfc9788 >>>>> >>>>> Thank you, >>>>> RFC Editor/ap >>>>> >>>>>> On Jul 15, 2025, at 1:14 PM, Daniel Kahn Gillmor >>>>>> <d...@fifthhorseman.net> wrote: >>>>>> >>>>>> Hi RFC Editors, all-- >>>>>> >>>>>> Attached is the updated XML that contains resolutions to all the >>>>>> issues that Bernie raised in his AUTH48 review. >>>>>> >>>>>> Bernie and Alexey and myself jointly considered the points he raised, >>>>>> and workshopped these fixes. We have consensus among the authors >>>>>> that they are all net improvements to the document, though we are >>>>>> happy to get feedback from the RFC Editor or the responsible AD (Hi, >>>>>> Roman!) if you'd prefer something different. >>>>>> >>>>>> This list is more numerous than most AUTH48 review changes i've >>>>>> participated in, but hopefully they're not too problematic. >>>>>> >>>>>> # Substantial Changes >>>>>> >>>>>> While the overwhelming majority of the changes are editorial or >>>>>> clarifications, there are a few places where cleanup resulted in >>>>>> edits that have some minor substantive changes. Please let us know >>>>>> if any of these are a problem. They are: >>>>>> >>>>>> ## Security Guidance on Applying the `hp` Parameter >>>>>> >>>>>> Section 10.2 ("Avoid Cryptographic Summary Confusion from the hp >>>>>> Parameter") has been tightened up to use bcp14 MUST where before it >>>>>> said >>>>>> (non-bcp14) "should", effectively requiring the composer to correctly >>>>>> set `hp="clear"` or `hp="cipher"` depending on whether they are >>>>>> encrypting or merely signing an end-to-end protected message. This >>>>>> is necessary for message recipients to be able to reason about the >>>>>> incoming message in the face of transport agents who might apply >>>>>> encryption in transit. >>>>>> >>>>>> ## Security Guidance on Escaping Legacy Display Elements >>>>>> >>>>>> Section 10.3 ("Caution About Composing with Legacy Display Elements") >>>>>> has been tightened up to use BCP 14 language (MUSTs and SHOULDs) >>>>>> where before it was looser and more descriptive. This is necessary >>>>>> because avoiding these steps can create significant security issues, >>>>>> particularly when replying to a message with a potentially malicious >>>>>> Subject. >>>>>> >>>>>> ## Pseudocode Cleanup >>>>>> >>>>>> The two pseudocode algorithms ReferenceHCP and Compose have been >>>>>> given subtle, mutually reinforcing improvements. The end result of >>>>>> the changes to the pseudocode is no change at all to the messages >>>>>> produced by their application. But the cleanup allows Compose to be >>>>>> simpler and ReferenceHCP to be more explicit about handling different >>>>>> contexts in which it might be invoked. >>>>>> >>>>>> ## IANA Update >>>>>> >>>>>> The text describing `hcp_shy` in the IANA table has been improved for >>>>>> clarity -- this is an editorial cleanup, but we wanted to flag it >>>>>> specifically as it probably needs to be passed along to IANA. >>>>>> >>>>>> # Questions for RFC Editor >>>>>> >>>>>> Finally, we have a few questions for the RFC editor about the draft >>>>>> itself: >>>>>> >>>>>> 1) In Section 1.1 ("Update to RFC 8551"), the rendered plain text >>>>>> version of the document appears to split "message/rfc822" across two >>>>>> lines, with the line break coming immediately after the "/" (U+002F >>>>>> SOLIDUS). The authors would prefer it if there was no line break in >>>>>> that string, but we don't know how to coax that behavior out of the >>>>>> XML input format. (there is no problem in the HTML output, but the >>>>>> PDF output may also have the same problem) Can you help us fix this? >>>>>> >>>>>> 2) In the course of the review, we realized that the document uses >>>>>> the terms "send" and "compose" somewhat interchangably, and likewise >>>>>> also "receive" and "render" somewhat interchangeably. While we >>>>>> think the XML included here is understandable as-is, we think it >>>>>> might be cleaner to try to use use "compose" more regularly for the >>>>>> message generation side and "render" more regularly for the message >>>>>> interpretation side. We have prepared an additional update to the >>>>>> XML that applies this change, but it's a fairly large change >>>>>> size-wise, since "send" and "receive" are relatively common words in >>>>>> the document. If you think our using "compose" and "render" more >>>>>> consistently throughout the document (instead of "send" and >>>>>> "receive") is worthwhile, please let us know. I can send you a >>>>>> version of the XML with that change applied as well. If you're OK >>>>>> with it as-is, we can live with it as-is too. >>>>>> >>>>>> 3) Finally, the MIME structure diagram misalignment in PDF that we >>>>>> are wrestling with in RFC-to-be 9787 also appears to apply to this >>>>>> draft. >>>>>> With the recent changes to xml2rfc >>>>>> (https://github.com/ietf-tools/xml2rfc/pull/1261) i think we can >>>>>> resolve this by switching to an entirely BOX DRAWINGS approach, as >>>>>> with 9787. Let us know if that's your preference, or if you'd rather >>>>>> we do something else with those diagrams. >>>>>> >>>>>> On behalf of the authors, >>>>>> >>>>>> --dkg >>>>>> >>>>>> >>>>>> On Thu 2025-07-10 21:55:43 +0200, Bernie Hoeneisen wrote: >>>>>>> The authors are working together on several issues I run into during >>>>>>> my >>>>>>> AUTH48 review. After all issues are resolved, DKG will send you a >>>>>>> new XML version. This is expected to happen sometime next week. >>>>>> >>>>>> <rfc9788.xml> >>>>> >>>> >>> >> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
