Hi Ben, Thank you for your reply. We have updated the document accordingly.
We have one remaining followup question regarding: >> 4) <!-- [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 "impair" should be updated: >> >> Note that this mitigation will frequently impair the performance of >> correctly implemented clients, especially when returning a 407 (Proxy >> Authentication Required) response. >> --> > > The NIST guidelines on inclusive language appear to have listed "impair" as a > "suggested" term when preferring inclusive language. If there is a > recommended alternative, here or elsewhere in the document, please let me > know. Would "impede" or "hinder" retain the intended meaning? The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9931.txt https://www.rfc-editor.org/authors/rfc9931.pdf https://www.rfc-editor.org/authors/rfc9931.html https://www.rfc-editor.org/authors/rfc9931.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9931-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9931-auth48diff.html (AUTH48 changes only) Note that it may be necessary for you to refresh your browser to view the most recent version. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9931 Thank you, Sarah Tarrant RFC Production Center > On Mar 3, 2026, at 10:17 AM, Ben Schwartz <[email protected]> > wrote: > > > From: [email protected] <[email protected]> > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on > > https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!Bt8RZUm9aw!6lVWMtIQpST6k_SRhtmZHMq7U-RranNAoZKcW2Z2N1zoob2k64I4z-bQGqEJV0-z1Pk0spt7NFHCkd1MXc18$ > > . --> > > Keywords: > * Request Smuggling > * False Start > * HTTP CONNECT > > > 2) <!-- [rfced] To reflect the text in Section 7.8 of RFC 9110, may we > > update "Upgrade request header field" to "Upgrade header field of a > > request"? > > > > Current: > > There are two mechanisms to request such a protocol transition. One > > mechanism is the Upgrade request header field ([HTTP], Section 7.8), > > which indicates that the client would like to use this connection for > > a protocol other than HTTP/1.1. ... > > > > Perhaps: > > There are two mechanisms to request such a protocol transition. One > > mechanism is the Upgrade header field of a request ([HTTP], Section 7.8), > > which indicates that the client would like to use this connection for > > a protocol other than HTTP/1.1. ... > > --> > > Proposed: > > There are two mechanisms to request such a protocol transition. One > mechanism is the Upgrade header field ([HTTP], Section 7.8). When included > in a request, this field indicates that the client would like to use this > connection for > a protocol other than HTTP/1.1. ... > > > 3) <!--[rfced] It is unclear what "similarly" is referring to in this > > sentence. > > Please review and let us know how this text may be clarified or if we > > may remove "similarly". > > > > Original: > > Post-transition protocols such as > > WebSocket [WEBSOCKET] similarly are often used to convey data chosen > > by a third party. > > > Perhaps: > > Post-transition protocols, such as > > WebSocket [WEBSOCKET], are often used to convey data chosen > > by a third party. > > --> > > Proposed: > > Post-transition protocols, such as WebSocket [WEBSOCKET], are also frequently > used to convey data chosen by a third party. > > > 4) <!-- [rfced] Please review the "Inclusive Language" portion of the online > > Style Guide > > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!Bt8RZUm9aw!6lVWMtIQpST6k_SRhtmZHMq7U-RranNAoZKcW2Z2N1zoob2k64I4z-bQGqEJV0-z1Pk0spt7NFHCkQy805ma$ > > > > > 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 "impair" should be updated: > > > > Note that this mitigation will frequently impair the performance of > > correctly implemented clients, especially when returning a 407 (Proxy > > Authentication Required) response. > > --> > > The NIST guidelines on inclusive language appear to have listed "impair" as a > "suggested" term when preferring inclusive language. If there is a > recommended alternative, here or elsewhere in the document, please let me > know. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
