Change:
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

Discussion:
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.