Change:
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?

Discussion:
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 :

order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del> <ins> bhttp request", a zero byte, and the header.  Note: repurposing discusses how alternative message formats might use a different "info" value. </ins> Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields

In pseudocode, this procedure is as follows: <del> 4.2. </del> <ins> 4.4. </ins> Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows:

Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and <del> nonce associated with "context". </del> <ins> nonce associated with "context".  Note: repurposing discusses how alternative message formats might use a different "context" value. </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows: <del> 4.3. </del> <ins> 4.5. </ins> Media types are used to identify Encapsulated Requests and Responses; see iana-req and iana-res for definitions of these media types. Evolution of the format of Encapsulated Requests and Responses is supported through the definition of new formats that are identified <del> by new media types. </del> <ins> by new media types.  New media types might be defined to use similar encapsulation with a different HTTP message format than in BINARY; see repurposing for guidance on reusing this encapsulation. Alternatively, a new encapsulation method might be defined. 4.6. The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  The and agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. Future specifications may repurpose the encapsulation mechanism described in this document.  This requires that the specification define a new media type.  The encapsulation process for that content type can follow the same process, using new constant strings for the HPKE info and exporter context inputs. For example, a future specification might encapsulate DNS messages, which use the "application/dns-message" media type RFC8484.  In creating a new, encrypted media types, specifications might define the use of string "application/dns-message request" (plus a zero byte and the header for the full value) for request encryption and the string "application/dns-message response" for response encryption. </ins> 5.

can use padding to reduce the effectiveness of traffic analysis. Padding is a capability provided by binary HTTP messages; see BINARY. <ins> If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message format might need to include padding support. </ins> 6.3.

different label in their use of HPKE.  The "message/bhttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "message/bhttp request" <del> label; see repurposing-the-encapsulation-format. </del> <ins> label; see repurposing. </ins> 6.5.

9. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  and target agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. Future specifications may repurpose the encapsulation mechanism described in hpke-encapsulation, provided that the content type of the encrypted payload is appropriately reflected in the HPKE info and context strings.  For example, if a future specification were to use the encryption mechanism in this specification for DNS messages, identified by the "application/dns-message" media type, then the HPKE info string SHOULD be "application/dns-message request" for request encryption, and the HPKE export context string should be "application/dns-message response" for response encryption. 10. </del> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <del> 10.1. </del> <ins> 9.1. </ins> The "application/ohttp-keys" media type identifies a used by Oblivious HTTP. <del> 10.2. </del> <ins> 9.2. </ins> The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request. <del> 10.3. </del> <ins> 9.3. </ins> The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <del> 10.4. </del> <ins> 9.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <del> 11.  References </del> <ins> 10.  References </ins> <del> 11.1.  URIs </del> <ins> 10.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types