Change:
Clients MAY establish QUIC connections using the host and port indicated in the URL for "https" URLs only Non-"https" origins are able to be delegated using Alt-Svc Cribs a lot of text from .
Are we waiting on a consensus call for this?
The call has been issued and is running until Saturday UTC. If you have comments, please make them now!
Excellent! Can't wait for this to land. (Looks like I need to finish reading my WG email :>)
NAME I'll get your comments as a separate PR.
S 2.4. This text seems quite a bit more restrictive than S 9.1.1. of RFC 7540, which just allows reuse as long as the SAN is present in the cert. Is that intentional?
I think that the intent was to present equivalent text. Though the thinking about coalescing has evolved some in the meantime. We should discuss where we think the state of this discussion is at and see if we can capture something sensible.
Yes, it'd be good to capture something more up-to-date if we can come to consensus on that. Is explicit signal meant to indicate DNS and/or ORIGIN frame? If so, maybe call those two out as examples?
NAME I think the dilemma is that some of those things don't exist yet for H3. For example, Mike did some earlier work to redefine ALTSVC frame for H3 but there is yet to be equivalent for ORIGIN or secondary certs.
Yes, it's intentional. RFC7540 allows coalescing based on the cert and DNS, because you're connected to the authoritative origin. However, HTTP/3 is never connected on the authoritative endpoint for an http(s?):// URL, so you need something else to tell you that's okay. This could be an Alt-Svc record for that origin delegating to the same UDP port. This could be an ORIGIN-for-H3 frame telling you to throw caution to the wind and trust the cert, if the client thinks that's sensible.
Discussed in London; also blocked on URL defining how a client decides which connection / server to ask for a given resource.
Discussed in ZRH. Waiting for HTTP changes to materialize.

Discussion:
Once a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection.  QUIC provides protocol <del> negotiation, stream-based multiplexing, and flow control.  An HTTP/3 endpoint can be discovered using HTTP Alternative Services; this process is described in greater detail in discovery. </del> <ins> negotiation, stream-based multiplexing, and flow control.  Discovery of an HTTP/3 endpoint is described in discovery. </ins> Within each stream, the basic unit of HTTP/3 communication is a frame (frames).  Each frame type serves a different purpose.  For example,

3.2. <ins> HTTP relies on the notion of an authoritative response: a response that has been determined to be the most appropriate response for that request given the state of the target resource at the time of response message origination by (or at the direction of) the origin server identified within the target URI.  Locating an authoritative server for an HTTP URL is discussed in Section 5.4 of SEMANTICS. The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URL.  If a server presents a certificate and proof that it controls the corresponding private key, then a client will accept a secured connection to that server as being authoritative for all origins with the "https" scheme and a host identified in the certificate. A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port, and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Connectivity problems (e.g., blocking UDP) can result in QUIC connection establishment failure; clients SHOULD attempt to use TCP- based versions of HTTP in this case. Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement always includes an explicit port, and URLs contain either an explicit port or a default port associated with the scheme. 3.2.1. </ins> An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame (ALTSVC), using the ALPN token defined in connection-

port and, if successful, send HTTP requests using the mapping described in this document. <del> Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection establishment failure, in which case the client SHOULD continue using the existing connection or try another alternative endpoint offered by the origin. </del> <ins> 3.2.2. Although HTTP is independent of the transport protocol, the "http" scheme associates authority with the ability to receive TCP connections on the indicated port of whatever host is identified within the authority component.  Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the authoritative server for a resource identified by an "http" URI.  However, protocol extensions such as ALTSVC permit the authoritative server to identify other services which are also authoritative and which might be reachable over HTTP/3. </ins> <del> Servers MAY serve HTTP/3 on any UDP port, since an alternative always includes an explicit port. </del> <ins> Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </ins> 3.3.

Once a connection exists to a server endpoint, this connection MAY be reused for requests with multiple different URI authority components. <del> The client MAY send any requests for which the client considers the server authoritative. An authoritative HTTP/3 endpoint is typically discovered because the client has received an Alt-Svc record from the request's origin which nominates the endpoint as a valid HTTP Alternative Service for that origin.  As required by RFC7838, clients MUST check that the nominated server can present a valid certificate for the origin before considering it authoritative.  Clients MUST NOT assume that an HTTP/3 endpoint is authoritative for other origins without an explicit signal. </del> <ins> In general, a server is considered authoritative for all URIs with the "https" scheme for which the hostname in the URI is present in the authenticated certificate provided by the server, either as the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate (see RFC6125).  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate. </ins> Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port pair, where the host is derived from a URI, a selected

different transport or TLS configurations but SHOULD avoid creating multiple connections with the same configuration. <del> Prior to making requests for an origin whose scheme is not "https," the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </del> Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the HTTP/3 session,