Original text:
An HTTP message (request or response) consists of: <del> the header field section, sent as a single HEADERS frame (see frame-headers), </del>  optionally, the content, if present, sent as a series of DATA frames (see frame-data), and <del> optionally, the trailer field section, if present, sent as a single HEADERS frame. </del>  <del> Header and trailer field sections are described in Sections 6.3 and 6.5 of SEMANTICS; the content is described in Section 6.4 of SEMANTICS. </del>  Receipt of an invalid sequence of frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; see errors.  In sections.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (malformed). <del> 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). </del>  The following pseudo-header fields are defined for requests: 7.2.5. The PUSH_PROMISE frame (type=0x5) is used to carry a promised request <del> header field section from server to client on a request stream, as in </del>  HTTP/2. The payload consists of: A large field section (request-response) can cause an implementation to commit a large amount of state.  Header fields that are critical <del> 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. </del>  An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size- constraints) setting to advise peers of limits that might apply on data.  Compression MUST NOT be used if the source of data cannot be reliably determined. <del> Further considerations regarding the compression of fields sections </del>  are described in QPACK. 10.7. 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 <del> HTTP message can include both header field and trailer field sections. </del>  An instruction that represents a field line, possibly by reference to the dynamic and static tables. 2.1. <del> An encoder converts a header or trailer field section into a series of representations by emitting either an indexed or a literal </del>  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

Reviewer comments:
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."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?

Revised text:
An HTTP message (request or response) consists of:  <ins> the header section, sent as a single HEADERS frame (see frame- headers), </ins> optionally, the content, if present, sent as a series of DATA frames (see frame-data), and  <ins> optionally, the trailer section, if present, sent as a single HEADERS frame. </ins>  <ins> 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. </ins> Receipt of an invalid sequence of frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; see errors.  In sections.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (malformed).  <ins> 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). </ins> The following pseudo-header fields are defined for requests: 7.2.5. The PUSH_PROMISE frame (type=0x5) is used to carry a promised request  <ins> header section from server to client on a request stream, as in </ins> HTTP/2. The payload consists of: A large field section (request-response) can cause an implementation to commit a large amount of state.  Header fields that are critical  <ins> 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. </ins> An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size- constraints) setting to advise peers of limits that might apply on data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  <ins> Further considerations regarding the compression of field sections </ins> are described in QPACK. 10.7. 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  <ins> HTTP message can include both header and trailer sections. </ins> An instruction that represents a field line, possibly by reference to the dynamic and static tables. 2.1.  <ins> An encoder converts a header or trailer section into a series of representations by emitting either an indexed or a literal </ins> 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