Change:
11. <ins> The encapsulated payload of an OHTTP request and response is a binary HTTP message BINARY.  Client and target agree on this encapsulated payload type by specifying the media type "message/bhttp" in the HPKE encapsulation info string and HPKE export context string for request and response encapsulation, respectively. Future specifications may repurpose the encapsulation mechanism described in hpke-encapsulation, provided that the content type of the encapsulated payload is appropriately reflected in the HPKE info and context strings.  For example, if a future specification were to use the encapsulation 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 encapsulation, and the HPKE export context string should be "application/dns-message response" for response encapsulation. 12. </ins> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <del> 12.  References </del> <ins> 13.  References </ins> <del> 12.1.  URIs </del> <ins> 13.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types

Discussion:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The encapsulated payload could be something other than HTTP. We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that.
The clear example here would be allowing just a DNS message body. As long as the client and target agreed, they could use that without the proxy knowing. We could just loosen the restrictions on what the body is, or we could use different content types (if you want the proxy to know what it is?).
I think that the way you would do that is to define a new media type for DNS and then just go for it. (Of course, you need to debate whether to include a length field and a transaction ID field.) Maybe we don't need to do that in this draft, but we could explain how that might look.
I'd do the following here (in line with ): Replace as the HPKE info string with the content-type of the inner message, be it or . That way, both client and target must agree on the type of encapsulated payload to actually use it. Thoughts?
That might work. We have "ohttp response" as the label for HKDF expansion on the response. What would you include there? Maybe you should just extend with "message/bhttp request" and "message/bhttp response" and then the swapping in the media type becomes trivial.
Yeah, that's what I had in mind.
Sorry about that. Misremembered how this worked; I should have double-checked.