Original text:
HTTP message encapsulation uses HPKE for request and response encryption. <del> An encapsulated HTTP request contains a binary-encoded HTTP message BINARY and no other fields; see fig-req-pt. </del>  An Encapsulated Request is comprised of a key identifier and a HPKE- protected request message.  HPKE protection includes an encapsulated 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>  Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and three 16-bit integers, respectively, each in network byte order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del>  Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields 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>  Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". 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>  5. Clients can use padding to reduce the effectiveness of traffic analysis.  Padding is a capability provided by binary HTTP messages; <del> see BINARY. </del>  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>  6.5. 9. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  Client 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>  The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP. <del> 10.2. </del>  The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request. <del> 10.3. </del>  The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <del> 10.4. </del>  IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <del> 11.  References </del>  <del> 11.1.  URIs </del>  [1] https://www.iana.org/assignments/media-types

Reviewer comments:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding. The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me

Revised text:
HTTP message encapsulation uses HPKE for request and response encryption.  <ins> This document defines how a binary-encoded HTTP request BINARY is encapsulated.  This Encapsulated Request format is identified by the iana-req.  Alternative encapsulations or message formats are indicated using the media type. The content of ""message/ohttp-req"" request encapsulation contains only a binary HTTP message; see fig-req-pt. </ins> An Encapsulated Request is comprised of a key identifier and a HPKE- protected request message.  HPKE protection includes an encapsulated in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes.  <ins> This document defines how a binary-encoded HTTP request BINARY is encapsulated.  This Encapsulated Response format is identified by the iana-res.  Alternative encapsulations or message formats are indicated using the media type. The content of ""message/ohttp-res"" response encapsulation contains only a binary HTTP message; see fig-res-pt. </ins> Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and three 16-bit integers, respectively, each in network byte order. Build "info" by concatenating the ASCII-encoded string "message/  <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 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  <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". Evolution of the format of Encapsulated Requests and Responses is supported through the definition of new formats that are identified  <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.4. The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  The Client and Oblivious Gateway Resource 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. Clients can use padding to reduce the effectiveness of traffic analysis.  Padding is a capability provided by binary HTTP messages;  <ins> see BINARY.  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"  <ins> label; see repurposing. </ins> 6.5. 9.  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).  <ins> 9.1. </ins> The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP.  <ins> 9.2. </ins> The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request.  <ins> 9.3. </ins> The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response.  <ins> 9.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types