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

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?