________________________________ 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]
