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

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?