Original text:
Therefore, the following two lists of Cookie header fields are semantically equivalent. <del> 8.1.2.6. A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). A request or response that includes message content can include a header field.  A request or response is also malformed if the value of a header field does not equal the sum of the DATA frame payload lengths that form the content.  A response that is defined to have no content, as described in HTTP, can have a non-zero header field, even though no content is included in DATA frames. Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a StreamErrorHandler of type PROTOCOL_ERROR. For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. 8.1.3. </del>  <del> This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. </del>  <del> An HTTP GET request includes control data and a request header with no message content and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields.  The HEADERS frame in the following has both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames are sent. </del>  <del> Similarly, a response that includes only control data and a response header is transmitted as a HEADERS frame (again, followed by zero or more CONTINUATION frames) containing the serialized block of response header fields. </del>  <del> An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA frame having the END_STREAM flag set: </del>  <del> Note that data contributing to any given field line could be spread between field block fragments.  The allocation of field lines to frames in this example is illustrative only. </del>  <del> A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag set: </del>  <del> An informational response using a 1xx status code other than 101 is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames. </del>  <del> A trailer section is sent as a field block after both the request or response field block and all the DATA frames have been sent.  The HEADERS frame starting the field block that comprises the trailer section has the END_STREAM flag set. </del>  <del> The following example includes both a 100 (Continue) status code, which is sent in response to a request containing a "100-continue" token in the Expect header field, and a trailer section: </del>  <del> 8.1.4. </del>  <del> In general, an HTTP client is unable to retry a non-idempotent request when an error occurs because there is no means to determine the nature of the error.  It is possible that some server processing occurred prior to the error, which could result in undesirable effects if the request were reattempted. </del>  <del> HTTP/2 provides two mechanisms for providing a guarantee to a client that a request has not been processed: </del>  <del> Requests that have not been processed have not failed; clients MAY automatically retry them, even those with non-idempotent methods. </del>  <del> A server MUST NOT indicate that a stream has not been processed unless it can guarantee that fact.  If frames that are on a stream are passed to the application layer for any stream, then REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame MUST include a stream identifier that is greater than or equal to the given stream identifier. </del>  <del> In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection.  Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request. </del>  <del> 8.2. </del>  HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
Therefore, the following two lists of Cookie header fields are semantically equivalent.  <ins> 8.3. </ins>  <ins> HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). </ins>  <ins> Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </ins>  <ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in a trailer section.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed. </ins>  <ins> All pseudo-header fields MUST appear in a field block before all regular field lines.  Any request or response that contains a pseudo- header field that appears in a field block after a regular field line MUST be treated as malformed. </ins>  <ins> 8.3.1. </ins>  <ins> The following pseudo-header fields are defined for HTTP/2 requests: </ins>  <ins> All HTTP/2 requests MUST include exactly one valid value for the </ins>  <ins> , </ins>  <ins> , and </ins>  <ins> pseudo-header fields, unless it is a CONNECT.  An HTTP request that omits mandatory pseudo-header fields is malformed. </ins>  <ins> Individual HTTP/2 requests do not carry an explicit indicator of protocol version.  All HTTP/2 messages implicitly have a protocol version of "2.0" (see HTTP). </ins>  <ins> 8.3.2. </ins>  <ins> For HTTP/2 responses, a single </ins>  <ins> pseudo-header field is defined that carries the HTTP status code field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed. </ins>  <ins> HTTP/2 responses implicitly have a protocol version of "2.0". </ins>  <ins> 8.4. </ins> HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in