4. <del> CAPSULE allows reliably sending request-related information end-to- </del> <ins> This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that allows endpoints to reliably communicate request-related information end-to- </ins> end, even in the presence of HTTP intermediaries. <del> CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL only be sent in client-initiated bidirectional streams. Intermediaries forward received CAPSULE frames on the same stream where it would forward DATA frames.  Each Capsule Type determines whether it is opaque or transparent to intermediaries: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries. </del> <ins> 4.1. This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both directions.  In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header section.  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. Definitions of new HTTP Methods or of new HTTP Upgrade Tokens can state that their data stream uses the Capsule Protocol.  If they do so, that means that the contents of their data stream uses the following format (using the notation from the "Notational Conventions" section of QUIC): A variable-length integer indicating the Type of the capsule. Endpoints that receive a capsule with an unknown Capsule Type MUST silently skip over that capsule. The length of the Capsule Value field following this field, encoded as a variable-length integer.  Note that this field can have a value of zero. The payload of this capsule.  Its semantics are determined by the value of the Capsule Type field. 4.2. </ins> <del> This specification of CAPSULE currently uses HTTP/3 frame type 0xffcab5.  If this document is approved, a lower number will be requested from IANA. </del> <ins> If the definition of an HTTP Method or HTTP Upgrade Token states that it uses the capsule protocol, its implementations MUST follow the following requirements: </ins> <del> The Type and Length fields follows the definition of HTTP/3 frames from H3.  The payload consists of: </del> <ins> A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response.  If a client receives a Content-Length or Transfer-Encoding header fields in a successful response, it MUST treat that response as malformed. </ins> <del> The type of this capsule. </del> <ins> A request message does not have content. </ins> <del> Data whose semantics depends on the Capsule Type. </del> <ins> A successful response message does not have content. Responses are not cacheable. 4.3. Intermediaries MUST operate in one of the two following modes: In this mode, the intermediary forwards the data stream between two associated streams without any modification of the data stream. In this mode, the intermediary terminates the data stream and parses all Capsule Type and Capsule Length fields it receives. Each Capsule Type determines whether it is opaque or transparent to intermediaries in participant mode: opaque capsules are forwarded unmodified while transparent ones can be parsed, added, or removed by intermediaries.  Intermediaries MAY modify the contents of the Capsule Data field of transparent capsule types. </ins> Unless otherwise specified, all Capsule Types are defined as opaque to intermediaries.  Intermediaries MUST forward all received opaque