Hi Authors, Per the XML file sent by Daniel, we have updated the other document files accordingly.
In addition the remaining questions about artwork/sourcecode (rfced question 19) and “the draft” (rfced question 17), there is one rfced question regarding IANA that has not yet been addressed, as well as some follow-up questions per discussion with Bernie. See below. > 16) <!--[rfced] We have included some specific questions about the IANA > text below. In addition to responding to those questions, please > review all of the IANA-related updates carefully and let us know > if any further updates are needed. > > a) In Section 12.1, does the "Author/Change Controller" information > only apply to the "HP-Outer" registration? If so, may we update the > text below to reflect "this entry" (instead of "these two entries") > as shown in option A? Or if it also applies to the "Content-Type" > registration, may we move it to the end of Section 12.2 and update > the text as shown in option B? > > Original: > The Author/Change Controller of these two entries (Section 4.5 of > [RFC3864]) should be the IETF itself. > > Perhaps A: > The Author/Change Controller (Section 4.5 of [RFC3864]) for this > entry is the IETF itself. > > Perhaps B: > The Author/Change Controller (Section 4.5 of [RFC3864]) > for the HP-Outer and Content-Type Header Field name > registrations is the IETF itself. ) Please let us know which suggested text is correct for clarity. >>> ) We have a couple of questions regarding the index. >>> a. We note that there is a lot of index linking throughout the document. >>> For it to be most useful, it is ideal that the index points to where the >>> term is defined, and perhaps other key occurrences, not at each instance >>> where the term is mentioned. Therefore, may we clean up the index to only >>> link to definitions and key occurrences? For example, for “Header >>> Confidentiality Policy” and “HCP”, we suggest only including links to >>> Section 1.7 and Section 3, Paragraph 2, as these are where the terms are >>> defined and expanded on. >>> b. Within instances of “No Header Confidentiality Policy”, only “Header >>> Confidentiality Policy” is linked. Was the intention to include an index >>> entry for “No Header Confidentiality Policy” (if yes, we suggest including >>> only one link to Section 3.2.3 (“No Header Confidentiality Policy”)), or >>> may we remove the links from these occurrences? >> DKG? > > No opinion. ) As Alexey and Bernie do not have any preference, we will await word from Daniel regarding the questions about the index. Should Daniel have no preference, we will streamline the index accordingly. > 4.4.4 > > [ TBD (@RFC-Editor, @DKG, @Alexey): Not sure whether the comma preceding "or" > is correctly set. Shouldn't this be like ] > > OLD: > > Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may > populate the composer view using a combination of the referenced message's > From, To, Cc, Reply-To, or Mail-Followup-To Header Fields or any other > signals. > > > NEW: > Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may > populate the composer view using a combination of the referenced message's > From, To, Cc, Reply-To or Mail-Followup-To Header Fields, or any other > signals. ) As “Header Fields” applies to “From”, “To”, “Cc”, “Reply-To”, and “Mail-Followup-To”, we believe the commas in the OLD text are correct. However, we could update as follows: Perhaps: Depending on whether it is a Reply, a Reply All, or a Forward, an MUA may populate the composer view using a combination of the referenced message's From Header Field, To Header Field, Cc Header Field, Reply-To Header Field, or Mail-Followup-To Header Field as well as any other signals. > * Appendix F.2. (minor) > > [ Note: The TXT version has the line break at an odd place. Suggest to remove > the introduced hyphen.] > > OLD: > > Although the PEF-2 scheme is only meant to be used between PEF- > 2-compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). > > NEW: > > Although the PEF-2 scheme is only meant to be used between PEF-2 > compatible MUAs, PEF-2 messages may end up at MUAs unaware of PEF-2 > (in which case, they typically render badly). ) With the hyphen removed, may we further update the text as follows? Perhaps: Although the PEF-2 scheme is only meant to be used between MUAs compatible with PEF-2, PEF-2 messages may end up at MUAs unaware of PEF-2 (in which case, they typically render badly). Daniel and Alexey - Note that Bernie has explicitly requested your input on some of the updates/questions. We have updated per Bernie’s suggestions, but please review his previous emails and let us know if further updates are needed. — FILES (please refresh) — The files have been posted here: 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) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9788 Thank you, RFC Editor/ap > On Jun 11, 2025, at 6:30 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > Hi RFC editors-- > > Apologies for my delay in processing this document. > > This message addresses most of the outstanding questions, but leaves two > things to be addressed in a later message: > > - Artwork/Sourcecode triage (rfced question 19) > - "the draft" (rfced question 17). > > I'm fine with the changes that Bernie and Alexey and Deb have pushed > into the document so far, and i'm attaching an updated XML file which > includes all of my proposed edits on top of those, > > > my responses to the initial questions for the record: > > On Tue 2025-05-20 18:19:01 -0700, rfc-edi...@rfc-editor.org wrote: >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. --> > > If it makes sense to include keywords that are unique wire format > strings, i would also include these strings: > > - HP-Outer > - hp-legacy-display > - hp > > >> 2) <!--[rfced] FYI - In the following sentence, we have updated "page 5" >> to "Section 2". Please review and let us know of any objections. >> >> Original: >> In some cases, some mail user agents cannot render message/rfc822 >> message subparts at all, in violation of baseline MIME requirements >> as defined on page 5 of [RFC2049]. >> >> Current: >> In some cases, some mail user agents cannot render message/rfc822 >> message subparts at all, which is in violation of baseline MIME >> requirements as defined in Section 2 of [RFC2049]. >> --> > > I'm ok with section 2 instead of page 5, though in this case, page 5 is > actually a narrower description because of the length of section 2 of > that document. I'm proposing changing it to "requirement 6 of Section 2 > of RFC 2049". > >> 3) <!--[rfced] Should "highest" be added to this sentence to describe the >> "extent possible"? >> >> Original: >> This document aims for backward compatibility with Legacy MUAs to the >> extent possible. >> >> Perhaps: >> This document aims for backward compatibility with Legacy MUAs to the >> highest extent possible. >> --> > > I disagree with this proposed change. If you want, we can re-order the > phrase, so that it becomes: > > To the extent possible, this document aims for backward compatibilty with > Legacy MUAs > > But i think the current phrasing is fine so i've left it untouched. > >> 4) <!--[rfced] To reflect how their usage is described in RFC 8126, we >> have updated "key words" to "policies" and "SPECIFICATION >> REQUIRED" and "IETF REVIEW" to "Specification Required" and "IETF >> Review", respectively (i.e., we capitalized only the first letter >> of each word and removed <bcp14> tags around "REQUIRED" in the >> XML). Note that all occurrences of these terms have been made >> lowercase. >> >> Additionally, may we move this text from the "Requirements Language" >> section to the "Terms" section as the first paragraph since these >> terms are not key words? >> >> One example >> >> Original: >> The key words "SPECIFICATION REQUIRED" and "IETF REVIEW" that appear >> in this document when used to describe namespace allocation are to be >> interpreted as described in [RFC8126]. >> >> Current: >> The policies "Specification Required" and "IETF Review" that appear >> in this document when used to describe namespace allocation are to be >> interpreted as described in [RFC8126]. >> --> > > I'm fine with these changes, thanks. > > >> 5) <!--[rfced] To match use in RFC 3156 and the companion document, we >> updated the expansion of "PGP/MIME" in the Abstract and Terms >> section as follows. Please let us know of any objections. >> >> Original (Abstract): >> The Header Protection scheme defined here is also applicable to >> messages with PGP/MIME cryptographic protections. >> >> Current: >> The Header Protection scheme defined here is also applicable to >> messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic >> protections. >> >> ... >> Original (Section 1.7): >> * PGP/MIME: MIME Security with OpenPGP (see [RFC3156]) >> >> Current: >> * PGP/MIME: Pretty Good Privacy with MIME (see [RFC3156]) >> --> > > RFC 3156 is actually titled "MIME Security with OpenPGP". I can live > with this change, but really the term "PGP" is rarely expanded, even in > the OpenPGP ecosystem. > >> 6) <!--[rfced] FYI - We have moved this text to the end of the Terms section >> since >> it does not match the definition list formatting of the other terms listed. >> Please let us know of any objections. >> >> Original: >> * Cryptographic Layer, Cryptographic Payload, Cryptographic >> Envelope, Cryptographic Summary, Structural Header Fields, Main >> Body Part, User-Facing Header Fields, and MUA are all used as >> defined in [I-D.ietf-lamps-e2e-mail-guidance] >> >> Current: >> Additionally, Cryptographic Layer, Cryptographic Payload, Cryptographic >> Envelope, Cryptographic Summary, Structural Header Fields, Main >> Body Part, User-Facing Header Fields, and MUA are all used as >> defined in [I-D.ietf-lamps-e2e-mail-guidance] >> --> > > This is fine, thanks. > >> 7) <!--[rfced] For clarity and consistency, may we update the phrasing of >> "Legacy receiving MUA" and "modern receiving clients" as follows? >> >> Original: >> The message generation guidance aims to minimize negative >> interactions with any Legacy receiving MUA while providing >> actionable cryptographic properties for modern receiving >> clients. >> >> Perhaps: >> The message generation guidance aims to minimize negative >> interactions with any Legacy MUA recipient while providing >> actionable cryptographic properties for modern client >> recipients. >> --> > > I disagree with this change, and prefer the change in the current XML, > which Bernie and Alexey produced. > >> 8) <!--[rfced] May we update "non-encrypted" to "unencrypted"? >> >> Original: >> A sending implementation MUST NOT produce a Cryptographic Payload >> with parameter hp="cipher" for a non-encrypted message (that is, >> where none of the Cryptographic Layers in the Cryptographic Envelope >> of the message provide encryption). >> >> Perhaps: >> A sending implementation MUST NOT produce a Cryptographic Payload >> with parameter hp="cipher" for an unencrypted message (that is, >> where none of the Cryptographic Layers in the Cryptographic Envelope >> of the message provide encryption). >> --> > > This is fine. > > >> 9) <!--[rfced] To improve readability, we have updated "at all" to >> "completely" >> and reworded the sentence below. Please review and let us know of any >> objections. >> >> Original: >> The receiving MUA MUST avoid rendering the identified Legacy Display >> Elements to the user at all, since it is aware of Header Protection >> and can render the actual protected Header Fields. >> >> Current: >> The receiving MUA MUST completely avoid rendering the identified Legacy >> Display Elements to the user, since it is aware of Header Protection >> and can render the actual protected Header Fields. >> --> > > This is fine. > > >> 10) <!--[rfced] To make this sentence more concise, may we remove "of the >> part"? >> >> Original: >> * Discard the leading lines of the body of the part up to and >> including the first entirely blank line. >> >> Perhaps: >> * Discard the leading lines of the body up to and including the >> first entirely blank line. >> --> > > I disagree with this, but am OK with the revised version that Bernie and > Alexey produced. > > >> 11) <!--[rfced] The <artwork> in Sections 5.2.2 and 5.2.3 includes the >> following attributes: charset=UTF-8 and hp-legacy-display=1. >> >> Should quotes appear around the "UTF-8" and "1" values in these >> instances per other use in the document? And should "UTF-8" be made >> lowercase for consistency, or are the lowercase instances different? >> >> Current: >> Content-Type: text/plain; charset=UTF-8 vs. >> Content-Type: text/plain; charset="utf-8" >> >> Content-Type: text/plain; charset="us-ascii"; hp-legacy-display="1"; vs. >> Content-Type: text/plain; charset=UTF-8; hp-legacy-display=1 >> --> > > the content-type parameter syntax itself is defined in > > https://www.rfc-editor.org/rfc/rfc2045#section-5.1 > > and it indicates that the value part of the parameter can either be a > raw token or a quoted-string. > > The rules for charset parameter handling are defined in > > https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2 > > and indicates that they are not case-sensitive. > > In alignment with Alexey and Bernie, I'm fine with leaving the variant > forms in the document; they potentially stand in for the range of > messages that might be found in the wild. > >> 12) <!--[rfced] As "Main Body Part" is a term used throughout the document, >> may we >> update this sentence as shown below? >> >> Original: >> The purpose of injecting a Legacy Display Element into each Main Body >> MIME part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> >> Perhaps: >> The purpose of injecting a Legacy Display Element into each MIME Main >> Body Part is to enable rendering of otherwise obscured Header Fields >> in Legacy MUAs that are capable of message decryption... >> --> > > I disagree with this original proposed change, but i like how y'all have > resolved this in the current document, by just dropping MIME entirely. > >> 13) <!--[rfced] Is a "mail transport system" the same thing as a "mail >> transport >> agent"? If so, may we update this sentence to use "mail transport agents" >> for consistency with the rest of the document? >> >> Original: >> In the future, some mail transport systems may accept and deliver >> messages with even less publicly visible metadata. >> >> Perhaps: >> In the future, some mail transport agents may accept and deliver >> messages with even less publicly visible metadata. >> --> > > Following Alexey, I think a mail transport system can be a collection of > mail transport agents, so i prefer to decline this change. > >> 14) <!--[rfced] To improve readability, may we update the phrasing of "may >> not >> expect to be injected by their MUA" as follows? >> >> Original: >> This can be >> especially problematic for Header Fields that are not user-facing, >> which the sender may not expect to be injected by their MUA. >> >> Perhaps: >> This can be >> especially problematic for Header Fields that are not user-facing; >> the sender may not expect these Header Fields to be injected by their MUA. >> --> > > I agree to this change. > >> 15) <!--[rfced] May we update "genericize" to "generalize"? >> >> Original: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/genericize the local part of the >> From address, the domain will still leak. >> >> Perhaps: >> So even if an >> ambitious HCP opts to remove the human-readable part from any From >> Header Field, and to standardize/generalize the local part of the >> From address, the domain will still leak. >> --> > > I disagree with this proposed change. This is in the context of trying > to mask as much of an e-mail address as possible in the From header > field. To do that masking, the text suggests that an ambitious HCP > might want to make the address more "standard" or more "generic". > making it more "general" doesn't help. > > For example: maybe I know that my outbound e-mail server for my > d...@example.com address is willing to relay any message from me that > i've written as though it comes from "unkn...@example.com". It might > offer this as a way to provide a sort of limited "hidden sender" while > retaining domain-level accountability (in the DKIM sense) for its peers > in the SMTP ecosystem. > > An MUA with knowledge of this domain policy and an ambitious HCP might > go ahead and replace "From: Daniel Kahn Gillmor <d...@example.com>" with > the generic "From: unkn...@example.com". But "unkn...@example.com" is > not "general". > >> 16) <!--[rfced] We have included some specific questions about the IANA >> text below. In addition to responding to those questions, please >> review all of the IANA-related updates carefully and let us know >> if any further updates are needed. >> >> a) In Section 12.1, does the "Author/Change Controller" information >> only apply to the "HP-Outer" registration? If so, may we update the >> text below to reflect "this entry" (instead of "these two entries") >> as shown in option A? Or if it also applies to the "Content-Type" >> registration, may we move it to the end of Section 12.2 and update >> the text as shown in option B? >> >> Original: >> The Author/Change Controller of these two entries (Section 4.5 of >> [RFC3864]) should be the IETF itself. >> >> Perhaps A: >> The Author/Change Controller (Section 4.5 of [RFC3864]) for this >> entry is the IETF itself. >> >> Perhaps B: >> The Author/Change Controller (Section 4.5 of [RFC3864]) >> for the HP-Outer and Content-Type Header Field name >> registrations is the IETF itself. >> >> b) FYI - We removed the blank columns from Tables 2 and 3. We also >> removed Table 4 (in Section 12.2) as one table is sufficient to >> show the addition of this document as a reference to the >> "Permanent Message Header Field Names" registry (see Table 3). >> >> c) We shortened the title of Section 12.2 as the hp and >> hp-legacy-display parameters are mentioned in the introductory >> sentence. Please let us know of any objections. >> >> Original: >> 12.2 Update Reference for Content-Type Header Field due to >> hp and hp-legacy-display Parameters >> >> Current: >> 12.2 Reference Update for the Content-Type Header Field >> >> d) FYI - In Section 12.3, we ordered the notes to match the order >> in the IANA registry <https://www.iana.org/assignments/mail-parameters/>; >> please let us know of any objections. >> --> > > Thank you for the close read and the cleanup. I'm fine with all these > changes. > >> 17) <!--[rfced] What does "the draft" refer to in the sentence below? >> Should this be updated to "the draft message"? Note that there are >> other occurrences like the example listed below that are used throughout >> the appendices of this document. >> >> Original: >> It uses the Header Protection scheme from the draft. >> >> Perhaps: >> It uses the Header Protection scheme from the draft message. >> --> > > Urgh, thanks for catching this infelicitous phrasing. Because this > string is embedded in the contents of each signed/encrypted message, we > probably need to re-generate the test vectors. > > In this case, "the draft" originally meant "this document" but it now > means "RFC 9788" i guess. I'll re-generate the messages and replace > them in a followup message. > > So i'm proposing to change it to: > > It uses the Header Protection scheme from RFC 9788. > > Any objections to that change? This will involve re-generating all the > test vectors, which is a bit surprising at this stage. But it's not > hard for me to do. I'll follow up on this in a subsequent message. > >> 18) <!--[rfced] FYI - We alphabetized the names listed in the >> Acknowledgements >> section. We believe that was the intent as only two were out of order. Let us >> know if you prefer the original order. >> --> > > Thanks, this is good. > >> 19) <!-- [rfced] We have some questions/comments regarding artwork and >> sourcecode: >> >> a) Please review each artwork element and let us know if any should be marked >> as sourcecode (or another element) instead. >> >> b) Some artwork elements are marked as type "ascii-art" while others are >> not. Please review and let us know if there are any artwork elements you >> would >> like to have marked as "ascii-art". >> >> c) Since the sourcecode type "text/x-hcp" is not part of the list at >> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>, >> may we update to sourcecode type "pseudocode"? Note that it is also >> acceptable to leave the "type" attribute not set. >> --> > > Deferred for a followup message. > >> 20) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is >> output >> in fixed-width font. In the txt output, there are no changes to the font, >> and the quotation marks have been removed. >> >> In the html and pdf outputs, the text enclosed in <em> is output in >> italics. In the txt output, the text enclosed in <em> appears with an >> underscore before and after. >> >> Please review carefully and let us know if the output is acceptable or if any >> updates are needed. >> >> Additionally, we note variances with <tt>, for example, Bcc'ed vs. >> <tt>Bcc</tt>'ed. Please review let us know if any updates are needed >> for consistency. >> --> > > I've wrapped Bcc uniformly in <tt> flags in the attached xml document. > > Otherwise, i think the document is in fine shape for its choices of font > styling. > >> 21) <!--[rfced] We note that the figures in the sections and appendices >> listed below are either misaligned slightly and/or have broken >> lines in the PDF output (the html and txt outputs display correctly). >> To avoid this issue, please let us know if replacing/redrawing >> the non-ASCII characters with ASCII characters is possible >> (this is commonly done for structure in YANG trees; see >> Section 5 of RFC 9731 as an example). Or if you have a >> different solution for a fix, please let us know. >> >> Misaligned: >> Section 1.9 >> Section 4.5.1 >> Section 4.5.2 >> Section 4.10.1 >> Appendices C.3.1-C.3.8 >> >> Broken Lines : >> Appendix C.1.3 >> Appendix C.1.5 >> Appendix C.1.6 >> Appendix C.1.7 >> Appendix C.1.8 >> Appendix C.2.2 >> Appendix C.2.3 >> Appendix C.2.4 >> Appendix C.2.5 >> Appendix C.2.6 >> Appendices C.3.9-C.3.17 >> --> > > "Misaligned" and "Broken lines" are symptoms of the same underlying > issue, which is that leading whitespace on a lines that begins with a > non-ASCII character are not being rendered in monospace font in PDF form. > > This is https://github.com/ietf-tools/xml2rfc/issues/1245 > > I would prefer that we keep the artwork as-is, since it works correctly > in html and txt, and instead fix the issue in xml2rfc's PDF generation. > >> 22) <!-- [rfced] Please review whether any of the notes in this document >> should be in the <aside> element. It is defined as "a container for >> content that is semantically less important or tangential to the >> content that surrounds it" >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> > > There are a lot of instances of the word "note" but i didn't identify > any of them that should be in the <aside> element. In many cases, > "Note" is used to identify a critical aspect of the analysis, which is > sort of the opposite of what <aside> is supposed to do as i understand > it. > >> 23) <!--[rfced] Acronyms >> >> a) FYI - We have added an expansion for the following abbreviation >> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> >> man in the middle (MITM) > > This should be machine-in-the middle, already fixed. > >> b) For the following terms, both the expansion and the acronym are >> used throughout the document. Would you like to use the expansion >> upon the first mention and the acronym for the rest of the document >> for consistency as recommended in the Web Portion of the Style Guide >> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>? >> >> Header Confidentiality Policy (HCP) >> Mail User Agent (MUA) > > Yes, i'm fine with following the style guide for MUA (i think the draft > as proposed already does) > > However, for HCP, this document describes several different HCPs, and > uses the term in their names (e.g. "Baseline Header Confidentiality > Policy") and in section titles as well. I'm not convinced that all of > these instances need to be replaced with "HCP", but i've gone through > the XML and updated a few of the remaining "Header Confidentiality > Policy" textual references to just "HCP", leaving the ones spelled out > if they are policy titles or section headers. >> >> 24) <!--[rfced] Terminology >> >> a) Throughout the text, the following terminology appears to be used >> inconsistently. Please review these occurrences and let us know if/how >> they may be made consistent. >> >> Legacy Message vs. Legacy message >> Method Signature vs. Method signature >> Non-Structural Header Field vs. non-structural Header Field >> Outer Header Section vs. outer Header Section >> user-facing vs. User-Facing > > I'm fine with all these changes. > >> b) As the following terminology appears to be used inconsistently >> throughout the document, may we update to use the form on the right? >> >> header protection > Header Protection > > I'm fine with this as well. > >> c) In this document, "Header Field" is consistently uppercase; however, it >> appears >> as "header field" (consistently lowercase) in the companion document as well >> as in >> RFCs 2045, 3864, 4021, 5322, and 8551. Please let us know if you would like >> to make >> this term lowercase to match the companion document and referenced RFCs or >> if you >> would like to leave it as is, which is also acceptable. Note that this >> document >> uses "Header Field" about 451 times and "Header Section" about 42 times. > > I'm fine with using Header Field in this document, and leaving it as > "header field" in the companion document. > >> d) Please review instances of the term "NULL" used in this document. >> Should they instead be "NUL" (that is, referring to the specific >> ASCII control code), "null character", or just "null"? > > I don't see any reference to "NULL" -- the only uses i see are "null", > and that is a well-defined and distinct meaning, both in the definition > of the hcp pseudocode, and the message composition algorithm framing. > >> e) FYI - We updated the document to reflect the forms on the right for >> consistency with the RFC Series and companion document. Please let us >> know of any objections. >> >> e-mail -> email >> electronic email -> email >> --> > > I personally prefer e-mail, but i'll make way for the RFC editor's > preferences here. I noted a couple more instances in the RFC where > section anchors still contained "e-mail" even though the section title > used "email". I've corrected them in the attached .xml. > >> 25) <!--[rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether the following should be updated: >> - dummy >> - man in the middle >> - whitespace >> >> In addition, please consider whether "traditional" should be updated for >> clarity. >> While the NIST website >> <https://web.archive.org/web/20250203031433/https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf> >> >> indicates that this term is potentially biased, it is also ambiguous. >> "Traditional" is a subjective term, as it is not the same for everyone. >> --> > > I believe these have been resolved satisfactorily. Thanks! > > --dkg > > <rfc9788.xml> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
