Draft: draft-ietf-quic-http

Commentary: continued ; found a bug in my regex that apparently missed the most common form of this . 🤦 ‍ 
 Close .... became . Including the in each would have worked , too , but failing to exclude a hex digit following would change every hex instance by matching everything up to the final character . 
 right ? In any case , this is good . And I have confirmed that the transport registries already include the padding for all the values .
Paragraph (version A):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with HTTP request or response content.
Paragraph (version B):
DATA frames (type=0x00) convey arbitrary, variable-length sequences
of bytes associated with HTTP request or response content.
Paragraph (version A):
The HEADERS frame (type=0x1) is used to carry an HTTP field section,
encoded using QPACK.  See QPACK for more details.
Paragraph (version B):
The HEADERS frame (type=0x01) is used to carry an HTTP field section,
encoded using QPACK.  See QPACK for more details.
Paragraph (version A):
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
server push prior to the push stream being received.  The CANCEL_PUSH
frame identifies a server push by Push ID (see server-push), encoded
as a variable-length integer.
Paragraph (version B):
The CANCEL_PUSH frame (type=0x03) is used to request cancellation of
a server push prior to the push stream being received.  The
CANCEL_PUSH frame identifies a server push by Push ID (see server-
push), encoded as a variable-length integer.
Paragraph (version A):
The SETTINGS frame (type=0x4) conveys configuration parameters that
affect how endpoints communicate, such as preferences and constraints
on peer behavior.  Individually, a SETTINGS parameter can also be
referred to as a "setting"; the identifier and value of each setting
parameter can be referred to as a "setting identifier" and a "setting
value".
Paragraph (version B):
The SETTINGS frame (type=0x04) conveys configuration parameters that
affect how endpoints communicate, such as preferences and constraints
on peer behavior.  Individually, a SETTINGS parameter can also be
referred to as a "setting"; the identifier and value of each setting
parameter can be referred to as a "setting identifier" and a "setting
value".
Paragraph (version A):
The PUSH_PROMISE frame (type=0x5) is used to carry a promised request
header section from server to client on a request stream, as in
HTTP/2.
Paragraph (version B):
The PUSH_PROMISE frame (type=0x05) is used to carry a promised
request header section from server to client on a request stream, as
in HTTP/2.
Paragraph (version A):
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 B):
The GOAWAY frame (type=0x07) 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 MAX_PUSH_ID frame (type=0xd) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in PUSH_PROMISE
and CANCEL_PUSH frames.  Consequently, this also limits the number of
push streams that the server can initiate in addition to the limit
maintained by the QUIC transport.
Paragraph (version B):
The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in PUSH_PROMISE
and CANCEL_PUSH frames.  Consequently, this also limits the number of
push streams that the server can initiate in addition to the limit
maintained by the QUIC transport.
Paragraph (version A):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.5 of SEMANTICS.
Paragraph (version B):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0d), and the
zero character (NUL, ASCII 0x0d) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.5 of SEMANTICS.
Paragraph (version A):
The KEY_UPDATE_ERROR error code (0xe) is used to signal errors
related to key updates.
Paragraph (version B):
The KEY_UPDATE_ERROR error code (0x0e) is used to signal errors
related to key updates.
Paragraph (version A):
The least significant bit (0x1) of the stream ID identifies the
initiator of the stream.  Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1).
Paragraph (version A):
The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1).
Paragraph (version A):
The stream space for each type begins at the minimum value (0x0
through 0x3 respectively); successive streams of each type are
created with numerically increasing stream IDs.  A stream ID that is
used out of order results in all streams of that type with lower-
numbered stream IDs also being opened.
Paragraph (version B):
The least significant bit (0x01) of the stream ID identifies the
initiator of the stream.  Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1).
Paragraph (version B):
The second least significant bit (0x02) of the stream ID
distinguishes between bidirectional streams (with the bit set to 0)
and unidirectional streams (with the bit set to 1).
Paragraph (version B):
The stream space for each type begins at the minimum value (0x00
through 0x03 respectively); successive streams of each type are
created with numerically increasing stream IDs.  A stream ID that is
used out of order results in all streams of that type with lower-
numbered stream IDs also being opened.
Paragraph (version A):
An Initial packet uses long headers with a type value of 0x0.  It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction.
Paragraph (version B):
An Initial packet uses long headers with a type value of 0x00.  It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and carries ACKs in either direction.
Paragraph (version A):
A 0-RTT packet uses long headers with a type value of 0x1, followed
by the Length and Packet Number fields; see long-header.  The first
byte contains the Reserved and Packet Number Length bits; see long-
header.  A 0-RTT packet is used to carry "early" data from the client
to the server as part of the first flight, prior to handshake
completion.  As part of the TLS handshake, the server can accept or
reject this early data.
Paragraph (version B):
A 0-RTT packet uses long headers with a type value of 0x01, followed
by the Length and Packet Number fields; see long-header.  The first
byte contains the Reserved and Packet Number Length bits; see long-
header.  A 0-RTT packet is used to carry "early" data from the client
to the server as part of the first flight, prior to handshake
completion.  As part of the TLS handshake, the server can accept or
reject this early data.
Paragraph (version A):
A Handshake packet uses long headers with a type value of 0x2,
followed by the Length and Packet Number fields; see long-header.
The first byte contains the Reserved and Packet Number Length bits;
see long-header.  It is used to carry cryptographic handshake
messages and acknowledgments from the server and client.
Paragraph (version B):
A Handshake packet uses long headers with a type value of 0x02,
followed by the Length and Packet Number fields; see long-header.
The first byte contains the Reserved and Packet Number Length bits;
see long-header.  It is used to carry cryptographic handshake
messages and acknowledgments from the server and client.
Paragraph (version A):
A Retry packet uses a long packet header with a type value of 0x3.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a retry; see validate-
handshake.
Paragraph (version B):
A Retry packet uses a long packet header with a type value of 0x03.
It carries an address validation token created by the server.  It is
used by a server that wishes to perform a retry; see validate-
handshake.
Paragraph (version A):
This parameter is an integer value specifying the initial flow
control limit for locally-initiated bidirectional streams.  This
limit applies to newly created bidirectional streams opened by the
endpoint that sends the transport parameter.  In client transport
parameters, this applies to streams with an identifier with the
least significant two bits set to 0x0; in server transport
parameters, this applies to streams with the least significant two
bits set to 0x1.
Paragraph (version A):
This parameter is an integer value specifying the initial flow
control limit for peer-initiated bidirectional streams.  This
limit applies to newly created bidirectional streams opened by the
endpoint that receives the transport parameter.  In client
transport parameters, this applies to streams with an identifier
with the least significant two bits set to 0x1; in server
transport parameters, this applies to streams with the least
significant two bits set to 0x0.
Paragraph (version A):
This parameter is an integer value specifying the initial flow
control limit for unidirectional streams.  This limit applies to
newly created unidirectional streams opened by the endpoint that
receives the transport parameter.  In client transport parameters,
this applies to streams with an identifier with the least
significant two bits set to 0x3; in server transport parameters,
this applies to streams with the least significant two bits set to
0x2.
Paragraph (version B):
This parameter is an integer value specifying the initial flow
control limit for locally-initiated bidirectional streams.  This
limit applies to newly created bidirectional streams opened by the
endpoint that sends the transport parameter.  In client transport
parameters, this applies to streams with an identifier with the
least significant two bits set to 0x00; in server transport
parameters, this applies to streams with the least significant two
bits set to 0x01.
Paragraph (version B):
This parameter is an integer value specifying the initial flow
control limit for peer-initiated bidirectional streams.  This
limit applies to newly created bidirectional streams opened by the
endpoint that receives the transport parameter.  In client
transport parameters, this applies to streams with an identifier
with the least significant two bits set to 0x01; in server
transport parameters, this applies to streams with the least
significant two bits set to 0x00.
Paragraph (version B):
This parameter is an integer value specifying the initial flow
control limit for unidirectional streams.  This limit applies to
newly created unidirectional streams opened by the endpoint that
receives the transport parameter.  In client transport parameters,
this applies to streams with an identifier with the least
significant two bits set to 0x03; in server transport parameters,
this applies to streams with the least significant two bits set to
0x02.