Change:
specifications. QUIC version 1 uses TLS version 1.3 or greater as its handshake <del> protocol.  HTTP/3 clients MUST indicate the target domain name during the TLS handshake.  This may be done using the Server Name Indication (SNI) RFC6066 extension to TLS or using some other mechanism. </del> <ins> protocol.  HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake.  If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) RFC6066 TLS extension unless an alternative mechanism for indicate the target host is used. </ins> QUIC connections are established as described in QUIC-TRANSPORT. During connection establishment, HTTP/3 support is indicated by

Discussion:
To avoid conflicts, this includes what appears to be the generally-agreed .
Something seems to have gone wrong with here.
Oh, yes. I missed which document this was in.
In reading PR, I noticed that we have the text (unchanged by that PR): HTTP/3 clients MUST indicate the target domain name during the TLS handshake. This may be done using the Server Name Indication (SNI) {{!RFC6066}} extension to TLS or using some other mechanism. I read this as saying that in the absence of "some other mechanism" the SNI extension must be present. But as I read 6066, it prohibits IP literals: Literal IPv4 and IPv6 addresses are not permitted in "HostName". As such, I'm not quite sure how to interpret the HTTP/3 MUST when the browser is requesting a URL with an IP literal as the host of the URL's. I could imagine two interpretations: When HTTP/3 says "target domain name" that implicitly excludes IP literals, so no SN extension is expected. When HTTP/3 says "target domain name" that implicitly includes IP literals, so an SNI extension is expected. (Or probably more likely, 3. I'm misunderstanding something more deeply) If 1 is the intended behavior it might be worth some text clarifying that. However, it seems like it would be "good" if QUIC handshakes always included the client's understanding of the hostname so I'd love the interpretation to be 2 (though that seems to conflict with 6066 so perhaps that's hard.) Thoughts?
For HTTP/1.1 and HTTP/2 over TLS, we do not send the IP literal in SNI. Chrome accidentally did it once, which broke Apache httpd. It got confused because IPv6 literals have colons. Of course, the compatibility issue does not apply to a new protocol like QUIC. It would be nice for QUIC to mandate SNI, and, all else equal, avoiding random TLS inconsistencies is good. But this rule is odd and "you MUST send SNI whenever you are supposed to send SNI" is tautological. TLS 1.3 says something woefully noncommittal: I dunno, everything is a mess.

:-( If we were doing things anew, perhaps we'd have stuck the port number in there too. (As it stands, TLS does not authenticate the port, yet the port is part of the origin, and I doubt HTTP servers reliably check the port in the Host header.)
Maybe the rule can be concretely: if you have something else/better use that, otherwise if you have a domain name, include SNI, and finally if you don't have a domain name (including IP literals), do whatever. The HTTP scheme permits a broader range of "host" identifiers than we usually contemplate, so the 3rd option has to catch more than just IP literals. TLS was always necessarily lax because different applications have different constraints, but the idea was to ensure that for cases where you have the ability to use SNI that you used it.
That sounds reasonable. How about some text like: HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake. This may be done using the Server Name Indication (SNI) {{!RFC6066}} extension to TLS or using some other mechanism. If the target host is valid for this mechanism (in the case of SNI this means the host is a domain name) the client MUST indicate the host using this mechanism.
I didn't check before, but I should point out that RFC6066 is very clear about IP literals: PR opened. NAME do you think that this is OK as editorial?
Right. This is what I said in my first post on this issue :) Thanks. Look great!
I think it's fine -- we're clarifying the requirement we already have. Nothing we previously allowed is being prohibited, and nothing previously prohibited is now allowed. However, you've based the PR on another one that's clearly not editorial, so.... Maybe we just do a consensus call on the combined change anyway.
I like NAME wording, but the content looks sound.