Draft: draft-ietf-quic-qpack

Commentary: HTTP Semantics refers to the field sections used at particular locations using terms " header section " and " trailer section . " However , the HTTP/3 draft sometimes calls them " header field section " and " trailer field section . " This PR addresses the inconsistency . It also fixes one instance " fields section . " 
 Of course I did ( not ) . Done in . 
 Have you checked to make sure QPACK matches as well ?
Paragraph (version A):
An ordered collection of HTTP field lines associated with an HTTP
message.  A field section can contain multiple field lines with
the same name.  It can also contain duplicate field lines.  An
HTTP message can include both header field and trailer field
sections.
Paragraph (version B):
An ordered collection of HTTP field lines associated with an HTTP
message.  A field section can contain multiple field lines with
the same name.  It can also contain duplicate field lines.  An
HTTP message can include both header and trailer sections.
Paragraph (version A):
An encoder converts a header or trailer field section into a series
of representations by emitting either an indexed or a literal
representation for each field line in the list; see field-line-
representations.  Indexed representations achieve high compression by
replacing the literal name and possibly the value with an index to
either the static or dynamic table.  References to the static table
and literal representations do not require any dynamic state and
never risk head-of-line blocking.  References to the dynamic table
risk head-of-line blocking if the encoder has not received an
acknowledgment indicating the entry is available at the decoder.
Paragraph (version B):
An encoder converts a header or trailer section into a series of
representations by emitting either an indexed or a literal
representation for each field line in the list; see field-line-
representations.  Indexed representations achieve high compression by
replacing the literal name and possibly the value with an index to
either the static or dynamic table.  References to the static table
and literal representations do not require any dynamic state and
never risk head-of-line blocking.  References to the dynamic table
risk head-of-line blocking if the encoder has not received an
acknowledgment indicating the entry is available at the decoder.
Paragraph (version A):
the header field section, sent as a single HEADERS frame (see
frame-headers),
Paragraph (version A):
optionally, the trailer field section, if present, sent as a
single HEADERS frame.
Paragraph (version A):
Header and trailer field sections are described in Sections 6.3 and
SEMANTICS.
Paragraph (version B):
the header section, sent as a single HEADERS frame (see frame-
headers),
Paragraph (version B):
optionally, the trailer section, if present, sent as a single
HEADERS frame.
Paragraph (version B):
Header and trailer sections are described in Sections 6.3 and 6.5 of
SEMANTICS; the content is described in Section 6.4 of SEMANTICS.
Paragraph (version A):
All pseudo-header fields MUST appear in the header field section
before regular header fields.  Any request or response that contains
a pseudo-header field that appears in a header field section after a
regular header field MUST be treated as malformed (malformed).
Paragraph (version B):
All pseudo-header fields MUST appear in the header section before
regular header fields.  Any request or response that contains a
pseudo-header field that appears in a header section after a regular
header field MUST be treated as malformed (malformed).
Paragraph (version A):
The PUSH_PROMISE frame (type=0x5) is used to carry a promised request
header field section from server to client on a request stream, as in
HTTP/2.
Paragraph (version B):
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 A):
A large field section (request-response) can cause an implementation
to commit a large amount of state.  Header fields that are critical
for routing can appear toward the end of a header field section,
which prevents streaming of the header field section to its ultimate
destination.  This ordering and other reasons, such as ensuring cache
correctness, mean that an endpoint likely needs to buffer the entire
header field section.  Since there is no hard limit to the size of a
field section, some endpoints could be forced to commit a large
amount of available memory for header fields.
Paragraph (version B):
A large field section (request-response) can cause an implementation
to commit a large amount of state.  Header fields that are critical
for routing can appear toward the end of a header section, which
prevents streaming of the header section to its ultimate destination.
This ordering and other reasons, such as ensuring cache correctness,
mean that an endpoint likely needs to buffer the entire header
section.  Since there is no hard limit to the size of a field
section, some endpoints could be forced to commit a large amount of
available memory for header fields.
Paragraph (version A):
Further considerations regarding the compression of fields sections
are described in QPACK.
Paragraph (version B):
Further considerations regarding the compression of field sections
are described in QPACK.