Change:
4. <del> HTTP message encapsulation uses HPKE for request and response encryption. </del> <ins> This document defines how a binary-encoded HTTP message BINARY is encapsulated using HPKE HPKE.  Separate media types are defined to distinguish request and response messages: </ins> <del> An encapsulated HTTP request contains a binary-encoded HTTP message BINARY and no other fields; see fig-req-pt. </del> <ins> An format defined in req-format is identified by the iana-req. </ins> <del> An is comprised of a key identifier and a HPKE-protected request message.  HPKE protection includes an encapsulated KEM shared secret (or "enc"), plus the AEAD-protected request message.  An is shown in fig-enc-request. request describes the process for constructing and processing an . </del> <ins> An format defined in res-format is identified by the iana-res. Alternative encapsulations or message formats are indicated using the media type; see req-res-media and repurposing. 4.1. A message in ""message/ohttp-req"" format protects a binary HTTP request message; see fig-req-pt. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An is comprised of a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or "enc"); and the HPKE-protected binary HTTP request message. An is shown in fig-enc-request. request describes the process for constructing and processing an . </ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. <del> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. </del> <ins> 4.2. </ins> <del> Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and processing an . </del> <ins> A message in ""message/ohttp-res"" format protects a binary HTTP response message; see fig-res-pt. This plaintext Response is encapsulated into a message in ""message/ ohttp-res"" form by generating an .  An is comprised of a nonce and the AEAD-protected binary HTTP response message. An is shown in fig-enc-response. response describes the process for constructing and processing an . </ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). <del> 4.1. </del> <ins> 4.3. </ins> encapsulate a request "request" using values from a :

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?