Change:
The ":authority" pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target <del> of CONNECT requests; see Section 3.2.3 of HTTP11) </del> <ins> of CONNECT requests; see Section 7.1 of SEMANTICS) </ins> The request stream remains open at the end of the request to carry the data to be transferred.  A CONNECT request that does not conform

Discussion:
Three of these are simple -- origin and asterisk form lives in Semantics now, and we didn't get an update to the new pointer. Those are in the first commit. The second commit might be more controversial. See .
NAME just a heads-up that this is aligning with http2-bis in referencing SEMANTICS, which says... I'm not totally thrilled with dropping that back to a SHOULD, but it has the caveat that requests will look malformed if you don't, so I think it covers it.
NAME said
NAME said
NAME This is text imported mostly-unchanged from RFC7540, but I'm always happy to improve upon the past. This point actually in the discussion of , which is rewording that paragraph slightly, but your point would still remain with the new text. The key is that HTTP fields are an extension point, and some fields are defined to have hop-by-hop semantics. The endpoint necessarily knows the meaning of all fields it generates, and so we can tell it that it MUST NOT generate a field with hop-by-hop semantics. However, the intermediary does not necessarily know the meaning of all fields some other endpoint sends through it. Another way to read this is "MUST remove all fields which are known to have hop-by-hop semantics, but we acknowledge you might miss some"; that's a difficult requirement to test. We've tended to use SHOULD for unenforceable MUSTs throughout these documents. If you'd like to suggest a better way to phrase it, I'm open to incorporating it into or a follow-up.
As NAME in URL, the core HTTP spec now has , written more clearly. We should just reference them.
That WFM. Barry
now includes the same text as URL
Great; sounds like I'll be moving to a Yes ballot when I see the revised draft posted. Thanks, Mike, and all. Barry
NAME points out that, in addition to a couple easily-resolved normative references to the HTTP/1.1 draft (this content has moved to Semantics), there's a normative reference to "chunked" transfer encoding being prohibited. But technically, this is still a MUST NOT for an informative reference.

One resolution would be to make it a statement of fact rather than a conformance requirement -- to say that the transfer codings defined by the HTTP/1.1 are HTTP/1.1-specific and not applicable to HTTP/3. But that's a broader assertion than just "chunked." Is there a reason we need to keep e.g. "Transfer-Encoding: gzip"?
My +1 goes to talking about transfer-encodings in general rather than just chunked, but as stated in the review comment, IIUC we already use different language for endpoints and intermediaries and therefore am afraid we have to keep doing so.
I think that the tweak to translation behaviour is probably necessary. I'll be opening a bug on h2 as well.NAME Thank you for your comments and the changes. I agree about the intent, and I am fine with retaining the SHOULD that we already have. I also like the updated text in the other section that explicitly states that intermediaries "MUST decode and remove transfer encodings."