Draft: draft-ietf-quic-http

Commentary: Clients MAY establish QUIC connections using the host and port indicated in the URL for "  " URLs only Non-"https " origins are able to be delegated using     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 ! Ca n't wait for this to land . ( Looks like I need to finish reading my WG email :) 
 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 ? 
 I think the dilemma is that some of those things do n't exist yet for H3 . For example ,  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    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 defining how a client decides which connection / server to ask for a given resource . 
 Discussed in ZRH . Waiting for HTTP changes to materialize .
Paragraph (version A):
Once a client knows that an HTTP/3 server exists at a certain
endpoint, it opens a QUIC connection.  QUIC provides protocol
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.
Paragraph (version B):
Once a client knows that an HTTP/3 server exists at a certain
endpoint, it opens a QUIC connection.  QUIC provides protocol
negotiation, stream-based multiplexing, and flow control.  Discovery
of an HTTP/3 endpoint is described in discovery.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version A):
Servers MAY serve HTTP/3 on any UDP port, since an alternative always
includes an explicit port.
Paragraph (version B):
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.
Paragraph (version A):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
The client MAY send any requests for which the client considers the
server authoritative.
Paragraph (version A):
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.
Paragraph (version B):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
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.
Paragraph (version A):
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.