Draft: draft-ietf-quic-http

Commentary: Section 2.2 . : " connection : A transport - layer connection between two endpoints , using QUIC as the transport protocol . connection error : An error that affects the entire HTTP/3 connection . " In a total of 11 places this document uses " HTTP/3 connection " . The word connection exists 213 times in this document ( HTML version ) . So are there a difference between connection and HTTP/3 Connection , and if it is can that be clearly expressed . Else maybe alignment would be better . Secondly , I think the above " connection " definition is likely missing one important aspect is n't it ? I have the impression that an " HTTP/3 " connection is a QUIC connection established with the purpose of communicating HTTP/3 over it . That intention is likely explicitly expressed at QUIC connection establishment using ALPN ? 
 So that pull request resolves the definition of the HTTP connection . Does the usage of HTTP/3 connection vs Connection in the document need adjustment ? In other words , can you please check all the usage of connection if there is difference and if anywhere it needs to be clarified that it is not an HTTP/3 connection ? 
 Based on , labeling this as " editorial " 
 Having looked through the occurrences of " connection " in the document , I mostly think it 's clear from context which type of connection we 're talking about . ( It also helps that an HTTP/3 connection is a QUIC connection , and so it 's rarely necessary to distinguish the two . ) I did a slightly aggressive pass in , but I think I 'm going to pare that down a bit . 
 Okay , I 've pushed a less - aggressive change as . 
 Thanks that commit appear good to me . I think with these changes this issue is resolved . 
 As I said in the Issue there likely need to be a review of the 200 + times the word " connection " is used in the document to determine if one need to stress that it is the HTTP/3 connection or some other connection . a couple of suggestions
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open (TFO).
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, QUIC has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable security to running TLS over TCP, with the improved
connection setup latency of TCP Fast Open (TFO).
Paragraph (version A):
Connection Setup and Management (connection-setup) covers how an
HTTP/3 endpoint is discovered and a connection is established.
Paragraph (version A):
Connection Closure (connection-closure) describes how connections
are terminated, either gracefully or abruptly.
Paragraph (version B):
Connection Setup and Management (connection-setup) covers how an
HTTP/3 endpoint is discovered and an HTTP/3 connection is
established.
Paragraph (version B):
Connection Closure (connection-closure) describes how HTTP/3
connections are terminated, either gracefully or abruptly.
Paragraph (version B):
A QUIC connection where the negotiated application protocol is
HTTP/3.
Paragraph (version A):
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):
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 TLS session with
that server as being authoritative for all origins with the "https"
scheme and a host identified in the certificate.
Paragraph (version A):
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
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple connections to the same IP address and UDP port using
different transport or TLS configurations but SHOULD avoid creating
multiple connections with the same configuration.
Paragraph (version A):
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
connection, the terminating endpoint SHOULD first send a GOAWAY frame
(connection-shutdown) so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
Paragraph (version A):
A server that does not wish clients to reuse connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 9.1.2 of HTTP2.
Paragraph (version B):
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
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple HTTP/3 connections to the same IP address and UDP port
using different transport or TLS configurations but SHOULD avoid
creating multiple connections with the same configuration.
Paragraph (version B):
Servers are encouraged to maintain open HTTP/3 connections for as
long as possible but are permitted to terminate idle connections if
necessary.  When either endpoint chooses to close the HTTP/3
connection, the terminating endpoint SHOULD first send a GOAWAY frame
(connection-shutdown) so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
Paragraph (version B):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 9.1.2 of HTTP2.
Paragraph (version A):
Each server push is assigned a unique Push ID by the server.  The
Push ID is used to refer to the push in various contexts throughout
the lifetime of the connection.
Paragraph (version B):
Each server push is assigned a unique Push ID by the server.  The
Push ID is used to refer to the push in various contexts throughout
the lifetime of the HTTP/3 connection.
Paragraph (version A):
Each QUIC endpoint declares an idle timeout during the handshake.  If
the connection remains idle (no packets received) for longer than
this duration, the peer will assume that the connection has been
closed.  HTTP/3 implementations will need to open a new connection
for new requests if the existing connection has been idle for longer
than the server's advertised idle timeout, and SHOULD do so if
approaching the idle timeout.
Paragraph (version B):
Each QUIC endpoint declares an idle timeout during the handshake.  If
the QUIC connection remains idle (no packets received) for longer
than this duration, the peer will assume that the connection has been
closed.  HTTP/3 implementations will need to open a new HTTP/3
connection for new requests if the existing connection has been idle
for longer than the server's advertised idle timeout, and SHOULD do
so if approaching the idle timeout.
Paragraph (version A):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of a connection by sending a
GOAWAY frame (frame-goaway).  The GOAWAY frame contains an identifier
that indicates to the receiver the range of requests or pushes that
were or might be processed in this connection.  The server sends a
client-initiated bidirectional Stream ID; the client sends a Push ID
(server-push).  Requests or pushes with the indicated identifier or
greater are rejected (request-cancellation) by the sender of the
GOAWAY.  This identifier MAY be zero if no requests or pushes were
processed.
Paragraph (version A):
The information in the GOAWAY frame enables a client and server to
agree on which requests or pushes were accepted prior to the
connection shutdown.  Upon sending a GOAWAY frame, the endpoint
SHOULD explicitly cancel (see request-cancellation and frame-cancel-
push) any requests or pushes that have identifiers greater than or
equal to that indicated, in order to clean up transport state for the
affected streams.  The endpoint SHOULD continue to do so as more
requests or pushes arrive.
Paragraph (version B):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of an HTTP/3 connection by
sending a GOAWAY frame (frame-goaway).  The GOAWAY frame contains an
identifier that indicates to the receiver the range of requests or
pushes that were or might be processed in this connection.  The
server sends a client-initiated bidirectional Stream ID; the client
sends a Push ID (server-push).  Requests or pushes with the indicated
identifier or greater are rejected (request-cancellation) by the
sender of the GOAWAY.  This identifier MAY be zero if no requests or
pushes were processed.
Paragraph (version B):
The information in the GOAWAY frame enables a client and server to
agree on which requests or pushes were accepted prior to the shutdown
of the HTTP/3 connection.  Upon sending a GOAWAY frame, the endpoint
SHOULD explicitly cancel (see request-cancellation and frame-cancel-
push) any requests or pushes that have identifiers greater than or
equal to that indicated, in order to clean up transport state for the
affected streams.  The endpoint SHOULD continue to do so as more
requests or pushes arrive.
Paragraph (version A):
Upon receipt of a GOAWAY frame, if the client has already sent
requests with a Stream ID greater than or equal to the identifier
contained in the GOAWAY frame, those requests will not be
processed.  Clients can safely retry unprocessed requests on a
different connection.  A client that is unable to retry requests
loses all requests that are in flight when the server closes the
connection.
Paragraph (version B):
Upon receipt of a GOAWAY frame, if the client has already sent
requests with a Stream ID greater than or equal to the identifier
contained in the GOAWAY frame, those requests will not be
processed.  Clients can safely retry unprocessed requests on a
different HTTP connection.  A client that is unable to retry
requests loses all requests that are in flight when the server
closes the connection.
Paragraph (version A):
An endpoint MAY send multiple GOAWAY frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR.
Paragraph (version B):
An endpoint MAY send multiple GOAWAY frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another HTTP connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR.
Paragraph (version A):
When HTTP fields and data are sent over QUIC, the QUIC layer handles
most of the stream management.  HTTP does not need to do any separate
multiplexing when using QUIC - data sent over a QUIC stream always
maps to a particular HTTP transaction or connection context.
Paragraph (version B):
When HTTP fields and data are sent over QUIC, the QUIC layer handles
most of the stream management.  HTTP does not need to do any separate
multiplexing when using QUIC - data sent over a QUIC stream always
maps to a particular HTTP transaction or to the entire HTTP/3
connection context.
Paragraph (version A):
A pair of unidirectional streams is used rather than a single
bidirectional stream.  This allows either peer to send data as soon
as it is able.  Depending on whether 0-RTT is enabled on the
connection, either client or server might be able to send stream data
first after the cryptographic handshake completes.
Paragraph (version B):
A pair of unidirectional streams is used rather than a single
bidirectional stream.  This allows either peer to send data as soon
as it is able.  Depending on whether 0-RTT is enabled on the QUIC
connection, either client or server might be able to send stream data
first after the cryptographic handshake completes.
Paragraph (version A):
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see control-streams) by each peer, and MUST NOT be sent
subsequently.  If an endpoint receives a second SETTINGS frame on the
control stream, the endpoint MUST respond with a connection error of
type H3_FRAME_UNEXPECTED.
Paragraph (version B):
SETTINGS frames always apply to an entire HTTP/3 connection, never a
single stream.  A SETTINGS frame MUST be sent as the first frame of
each control stream (see control-streams) by each peer, and MUST NOT
be sent subsequently.  If an endpoint receives a second SETTINGS
frame on the control stream, the endpoint MUST respond with a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the connection where
resumption information was provided, but MAY opt not to store
settings in certain cases (e.g., if the session ticket is received
before the SETTINGS frame).  A client MUST comply with stored
settings - or default values, if no values are stored - when
attempting 0-RTT.  Once a server has provided new settings, clients
MUST comply with those values.
Paragraph (version B):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the HTTP/3
connection where resumption information was provided, but MAY opt not
to store settings in certain cases (e.g., if the session ticket is
received before the SETTINGS frame).  A client MUST comply with
stored settings - or default values, if no values are stored - when
attempting 0-RTT.  Once a server has provided new settings, clients
MUST comply with those values.
Paragraph (version A):
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
a connection by either endpoint.  GOAWAY allows an endpoint to stop
accepting new requests or pushes while still finishing processing of
previously received requests and pushes.  This enables administrative
actions, like server maintenance.  GOAWAY by itself does not close a
connection.
Paragraph (version B):
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
an HTTP/3 connection by either endpoint.  GOAWAY allows an endpoint
to stop accepting new requests or pushes while still finishing
processing of previously received requests and pushes.  This enables
administrative actions, like server maintenance.  GOAWAY by itself
does not close a connection.
Paragraph (version A):
The GOAWAY frame applies to the connection, not a specific stream.  A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
The GOAWAY frame applies to the entire connection, not a specific
stream.  A client MUST treat a GOAWAY frame on a stream other than
the control stream as a connection error (errors) of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The maximum Push ID is unset when a connection is created, meaning
that a server cannot push until it receives a MAX_PUSH_ID frame.  A
client that wishes to manage the number of promised server pushes can
increase the maximum Push ID by sending MAX_PUSH_ID frames as the
server fulfills or cancels server pushes.
Paragraph (version B):
The maximum Push ID is unset when an HTTP/3 connection is created,
meaning that a server cannot push until it receives a MAX_PUSH_ID
frame.  A client that wishes to manage the number of promised server
pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames
as the server fulfills or cancels server pushes.
Paragraph (version A):
Frame types of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
can be sent on any open stream when application-layer padding is
desired.  They MAY also be sent on connections where no data is
currently being transferred.  Endpoints MUST NOT consider these
frames to have any meaning upon receipt.
Paragraph (version B):
Frame types of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown
types be ignored (extensions).  These frames have no semantics, and
can be sent on any open stream when application-layer padding is
desired.  They MAY also be sent on open streams in connections where
no data is currently being transferred.  Endpoints MUST NOT consider
these frames to have any meaning upon receipt.
Paragraph (version A):
The following error codes are defined for use when abruptly
terminating streams, aborting reading of streams, or immediately
closing connections.
Paragraph (version B):
The following error codes are defined for use when abruptly
terminating streams, aborting reading of streams, or immediately
closing HTTP/3 connections.
Paragraph (version A):
A stream required by the connection was closed or reset.
Paragraph (version B):
A stream required by the HTTP/3 connection was closed or reset.
Paragraph (version A):
The connection established in response to a CONNECT request was
reset or abnormally closed.
Paragraph (version B):
The TCP connection established in response to a CONNECT request
was reset or abnormally closed.
Paragraph (version A):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size-
constraints) setting to advise peers of limits that might apply on
the size of field sections.  This setting is only advisory, so
endpoints MAY choose to send field sections that exceed this limit
and risk having the request or response being treated as malformed.
This setting is specific to a connection, so any request or response
could encounter a hop with a lower, unknown limit.  An intermediary
can attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Paragraph (version B):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size-
constraints) setting to advise peers of limits that might apply on
the size of field sections.  This setting is only advisory, so
endpoints MAY choose to send field sections that exceed this limit
and risk having the request or response being treated as malformed.
This setting is specific to an HTTP/3 connection, so any request or
response could encounter a hop with a lower, unknown limit.  An
intermediary can attempt to avoid this problem by passing on values
presented by different peers, but they are not obligated to do so.
Paragraph (version A):
Which endpoint on a connection may initiate a stream of this type.
Values are "Client", "Server", or "Both".
Paragraph (version B):
Which endpoint on an HTTP/3 connection may initiate a stream of
this type.  Values are "Client", "Server", or "Both".